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

CVSROOT:    /cvsroot
Module name:    pgsql-server
Changes by:    tgl@postgresql.org    03/05/03 20:03:55

Modified files:
    doc/src/sgml/ref: create_table.sgml create_table_as.sgml
    src/backend/parser: gram.y

Log message:
    When a TIMESTAMP, TIME, or INTERVAL precision is specified larger than our
    implementation limits, do not issue an ERROR; instead issue a NOTICE and use
    the max supported value.  Per pgsql-general discussion of 28-Apr, this is
    needed to allow easy porting from pre-7.3 releases where the limits were
    higher.

    Unrelated change in same area: accept GLOBAL TEMP/TEMPORARY as a synonym
    for TEMPORARY, as per pgsql-hackers discussion of 15-Apr.  We previously
    rejected it, but that was based on a misreading of the spec --- SQL92's
    GLOBAL temp tables are really closer to what we have than their LOCAL ones.

Tom Lane writes:

>     When a TIMESTAMP, TIME, or INTERVAL precision is specified larger than our
>     implementation limits, do not issue an ERROR; instead issue a NOTICE and use
>     the max supported value.  Per pgsql-general discussion of 28-Apr, this is
>     needed to allow easy porting from pre-7.3 releases where the limits were
>     higher.

I'm not happy with this change.  If someone explicitly put in a higher
limit in his old applications, he expressed that he needed it, so he needs
to see an error and adjust his applications.  (Or he didn't know what he
was doing, but we don't cater to those people.)

--
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> When a TIMESTAMP, TIME, or INTERVAL precision is specified larger than our
>> implementation limits, do not issue an ERROR; instead issue a NOTICE and use
>> the max supported value.  Per pgsql-general discussion of 28-Apr, this is
>> needed to allow easy porting from pre-7.3 releases where the limits were
>> higher.

> I'm not happy with this change.  If someone explicitly put in a higher
> limit in his old applications, he expressed that he needed it, so he needs
> to see an error and adjust his applications.  (Or he didn't know what he
> was doing, but we don't cater to those people.)

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.  You could argue this either way, certainly, but our past practice
has been to try not to error out when loading a dump.

            regards, tom lane

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

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