Robert Haas <robertmh...@gmail.com> writes: > On Thu, Sep 3, 2020 at 11:50 AM Mark Dilger > <mark.dil...@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 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. regards, tom lane