Re: problems restoring 7.2.1 dump to 7.3.2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ralph Graulich <maillist(at)shauny(dot)de>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: problems restoring 7.2.1 dump to 7.3.2
Date: 2003-04-28 16:52:59
Message-ID: 23430.1051548779@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Ralph Graulich <maillist(at)shauny(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Robert Fitzpatrick 2003-04-28 17:12:51 Setting a field to default if blank value
Previous Message Tom Lane 2003-04-28 16:35:16 Re: timestamps and dates