> On Sep 2, 2020, at 1:33 AM, John Naylor <john.naylor@2ndquadrant.com> wrote:
>
> On Tue, Sep 1, 2020 at 10:00 PM Mark Dilger
> <mark.dilger@enterprisedb.com> wrote:
>>
>> Some changes were made on another thread [1] for the deprecation notices, committed recently by Tom, and I think
thispatch set is compatible with what was done there. This patch set is intended for commit against master, targeted
forPostgreSQL 14, so the deprecation notices are removed along with the things that were deprecated. The references to
right-unaryoperators that you call out, above, have been removed.
>
> Hi Mark,
>
> Looks good. Just a couple things I found in 0001:
>
> The factorial operators should now be removed from func.sgml.
Right you are. Removed in v7.
> For pg_dump, should we issue a pg_log_warning() (or stronger)
> somewhere if user-defined postfix operators are found? I'm looking at
> the example of "WITH OIDS" in pg_dump.c.
Since newer pg_dump binaries can be used to dump data from older servers, and since users might then load that dump
backinto an older server, I think doing anything stronger than a pg_log_warning() would be incorrect. I did not find
precedentsunder comparable circumstances for taking stronger actions than pg_log_warning. I assume we can't, for
example,omit the operator from the dump, nor can we abort the process.
A pg_log_warning has been added in v7.
Dumping right-unary (postfix) operators should work (with a warning) in v7. I think pg_dump in v6 was broken in this
regard.
> Nitpick: these can be removed, since we already test factorial() in this file:
>
> -SELECT 4!;
> -SELECT !!3;
> +SELECT factorial(4);
> +SELECT factorial(3);
I was on the fence between removing those (as you suggest) vs. converting them to function calls (as v6 did). They are
removedin v7.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company