Re: pgsql-server/ oc/src/sgml/ref/create_table.sgm ... - Mailing list pgsql-committers

From Peter Eisentraut
Subject Re: pgsql-server/ oc/src/sgml/ref/create_table.sgm ...
Date
Msg-id Pine.LNX.4.44.0305262357040.2822-100000@peter.localdomain
Whole thread Raw
In response to Re: pgsql-server/ oc/src/sgml/ref/create_table.sgm ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgsql-server/ oc/src/sgml/ref/create_table.sgm ...
List 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 by date:

Previous
From: momjian@developer.postgresql.org (Bruce Momjian - CVS)
Date:
Subject: pgsql-server/src/backend/utils/adt float.c
Next
From: Tom Lane
Date:
Subject: Re: pgsql-server/ oc/src/sgml/ref/create_table.sgm ...