Re: factorial function/phase out postfix operators?

> On Sep 11, 2020, at 8:36 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Sep 3, 2020 at 11:50 AM Mark Dilger
>> <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
>>> 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.
>
>> I'm not sure that this is the right solution. Generally, the
>> recommendation is that you should use the pg_dump that corresponds to
>> the server version where you want to do the reload, so if you're
>> hoping to dump 9.6 and restore on 11, you should be using the pg_dump
>> from 11, not 14. So my thought would be that if there are user-defined
>> postfix operators, pg_dump ought to error out. However, that could be
>> inconvenient for people who are using pg_dump in ways that are maybe
>> not what we would recommend but which may happen to work but for this
>> issue, so I'm not sure. On the third hand, though, we think that there
>> are very few user-defined postfix operators out there, so if we just
>> give an error, we probably won't be inconveniencing many people.
>
> My inclination is to simply not change pg_dump. There is no need to break
> the use-case of loading the output back into the server version it came
> from, if we don't have to. If the output is getting loaded into a server
> that lacks postfix operators, that server can throw the error. There's no
> real gain in having pg_dump prejudge the issue.

I think some kind of indication that the dump won't be loadable is useful if they're planning to move the dump file across an expensive link, or if they intend to blow away the old data directory to make room for the new. Whether that indication should be in the form of a warning or an error is less clear to me. Whatever we do here, I think it sets a precedent for how such situations are handled in the future, so maybe focusing overmuch on the postfix operator issue is less helpful than on the broader concept. What, for example, would we do if we someday dropped GiST support? Print a warning when dumping a database with GiST indexes? Omit the indexes? Abort the dump?

The docs at https://www.postgresql.org/docs/12/app-pgdump.html say:

> Because pg_dump is used to transfer data to newer versions of PostgreSQL, the output of pg_dump can be expected to load into PostgreSQL server versions newer than pg_dump's version.
<snip>
> Also, it is not guaranteed that pg_dump's output can be loaded into a server of an older major version — not even if the dump was taken from a server of that version.

I think somewhere around here the docs need to call out what happens when the older major version supported a feature that has been dropped from the newer major version.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company