Re: factorial function/phase out postfix operators?

> On Sep 2, 2020, at 1:33 AM, John Naylor <john(dot)naylor(at)2ndquadrant(dot)com> wrote:
>
> On Tue, Sep 1, 2020 at 10:00 PM Mark Dilger
> <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
>>
>> Some changes were made on another thread [1] for the deprecation notices, committed recently by Tom, and I think this patch set is compatible with what was done there. This patch set is intended for commit against master, targeted for PostgreSQL 14, so the deprecation notices are removed along with the things that were deprecated. The references to right-unary operators 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 back into an older server, I think doing anything stronger than a pg_log_warning() would be incorrect. I did not find precedents under 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 removed in v7.