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

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql-server/ oc/src/sgml/ref/create_table.sgm ...
Date: 2003-05-26 23:36:26
Message-ID: Pine.LNX.4.44.0305262357040.2822-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)gmx(dot)net

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2003-05-27 01:33:38 Re: pgsql-server/ oc/src/sgml/ref/create_table.sgm ...
Previous Message Tom Lane 2003-05-26 20:05:31 pgsql-server/src/interfaces/libpq fe-exec.c