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.
regards, tom lane
