Re: factorial function/phase out postfix operators?
От | Tom Lane |
---|---|
Тема | Re: factorial function/phase out postfix operators? |
Дата | |
Msg-id | 392568.1599838568@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: factorial function/phase out postfix operators? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: factorial function/phase out postfix operators?
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: