From: | Dennis Gearon <gearond(at)cvc(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Ralph Graulich <maillist(at)shauny(dot)de>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: problems restoring 7.2.1 dump to 7.3.2 |
Date: | 2003-04-28 17:24:15 |
Message-ID: | 3EAD63BF.3050600@cvc.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I think the warning idea is sound.
Tom Lane wrote:
> 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dennis Gearon | 2003-04-28 17:26:07 | Re: Setting a field to default if blank value |
Previous Message | Robert Fitzpatrick | 2003-04-28 17:12:51 | Setting a field to default if blank value |