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

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> 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').

You have a point, but I'm not really convinced.  What else is the user
going to do, except lower the requested precision to what the new
backend supports?  Why should we force him to manually edit his dump,
rather than making the obvious automatic adjustment?  AFAICS the only
argument for an ERROR over a NOTICE is that someone might fail to notice
the NOTICE in a pile of noise messages from a reload.  Which is a
possible problem surely, but is it important enough to force people to
find ways to edit large dump files?

I don't really buy the argument that someone who requested TIME(13) or
some such really knew what they were doing and need a fix-this-or-die
failure as a form of notification that they weren't going to get it.
The precision limit reduction in CVS tip does not correspond to taking
away functionality that used to exist, only to not promising more than
we could deliver.

            regards, tom lane