Re: factorial function/phase out postfix operators? - Mailing list pgsql-hackers

> On Sep 11, 2020, at 8:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Sep 3, 2020 at 11:50 AM Mark Dilger
>> <mark.dilger@enterprisedb.com> wrote:
>>> 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. 
>
>> 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
acrossan expensive link, or if they intend to blow away the old data directory to make room for the new.  Whether that
indicationshould be in the form of a warning or an error is less clear to me.  Whatever we do here, I think it sets a
precedentfor how such situations are handled in the future, so maybe focusing overmuch on the postfix operator issue is
lesshelpful than on the broader concept.  What, for example, would we do if we someday dropped GiST support?  Print a
warningwhen 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
loadinto 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
thedump 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
thathas been dropped from the newer major version. 

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