Re: pgsql-server/ oc/src/sgml/ref/create_table.sgm ...
От | Peter Eisentraut |
---|---|
Тема | Re: pgsql-server/ oc/src/sgml/ref/create_table.sgm ... |
Дата | |
Msg-id | Pine.LNX.4.44.0305262357040.2822-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: pgsql-server/ oc/src/sgml/ref/create_table.sgm ... (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql-server/ oc/src/sgml/ref/create_table.sgm ...
|
Список | pgsql-committers |
Tom Lane writes: > The person who actually ran into the situation objected to getting an > error; he felt the system ought to do the best it could with his dump > file. But the backend doesn't know whether it's dealing with a dump file in an upgrade situation or just a user requesting unsupported values. > You could argue this either way, certainly, but our past practice has > been to try not to error out when loading a dump. The overriding principle is that if a user requests something that cannot be serviced, an error is raised. We do try to allow smooth reloading of old dump files, but only if the functionality doesn't change when doing so (e.g., opaque -> language_handler). We have never done that when the no longer supported functionality had been explicitly selected by the user (e.g., timestamp 'current'). -- Peter Eisentraut peter_e@gmx.net
В списке pgsql-committers по дате отправления: