Re: problems restoring 7.2.1 dump to 7.3.2 - Mailing list pgsql-general

From Tom Lane
Subject Re: problems restoring 7.2.1 dump to 7.3.2
Date
Msg-id 23430.1051548779@sss.pgh.pa.us
Whole thread Raw
In response to Re: problems restoring 7.2.1 dump to 7.3.2  (Ralph Graulich <maillist@shauny.de>)
Responses Re: problems restoring 7.2.1 dump to 7.3.2  (Dennis Gearon <gearond@cvc.net>)
Re: problems restoring 7.2.1 dump to 7.3.2  (Ralph Graulich <maillist@shauny.de>)
List pgsql-general
Ralph Graulich <maillist@shauny.de> writes:
>>> [Timestamp problem]

>> This seems quite strange.  I could not duplicate it using either 7.2 or
>> 7.3 pg_dump from a 7.2 server.  Do you recall exactly how those fields
>> were declared?  How do they show up in psql \d commands?

> Double checked the table definitions in the reactivated 7.2.1 version:
>  lastchanged   | timestamp(13) without time zone |

Hm.  I created a table in a 7.2.4 server:

ts=# create table zit(lastchanged     TIMESTAMP(13) WITHOUT TIME ZONE);
CREATE

and dumped it with 7.3.2 pg_dump:

CREATE TABLE zit (
    lastchanged timestamp(13) without time zone
);

No (16) anywhere.  And I see nothing in the CVS logs that looks like a
relevant patch between 7.2.1 and 7.2.4.  So I'm mystified why you're
seeing (16).

Now, the (13) version is still going to fail in 7.3, because we
tightened the allowed range of timestamp precisions:

ERROR:  TIMESTAMP(13) precision must be between 0 and 6

I wonder whether we should reduce that ERROR to a WARNING, and
substitute the max allowed precision instead of failing out.
As-is, it's going to be painful to load dump files containing
what had been a perfectly legitimate declaration in 7.2.
Comments anyone?

            regards, tom lane


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: timestamps and dates
Next
From: "Robert Fitzpatrick"
Date:
Subject: Setting a field to default if blank value