From: | "Rod Taylor" <rbt(at)zort(dot)ca> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Hackers List" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Making serial survive pg_dump |
Date: | 2002-06-13 21:30:30 |
Message-ID: | 06a001c21321$8b54e380$fe01a8c0@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
--
Rod
----- Original Message -----
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Rod Taylor" <rbt(at)zort(dot)ca>
Cc: "Hackers List" <pgsql-hackers(at)postgresql(dot)org>
Sent: Thursday, June 13, 2002 9:46 AM
Subject: Re: [HACKERS] Making serial survive pg_dump
> "Rod Taylor" <rbt(at)zort(dot)ca> writes:
> > Store sequence information in the SERIAL creation statement:
> > CREATE TABLE tab (col1 SERIAL(<start num>, <sequence name>));
>
> This is wrong because it loses the separation between schema and
data.
> I do agree that it would be nice if pg_dump recognized serial
columns
> and dumped them as such --- but the separate setval call is still
the
> appropriate technique for messing with the sequence contents. We do
> not need a syntax extension in CREATE.
Ok, keeping the setval is appropriate. Are there any problems with a
SERIAL(<sequence name>) implementation?
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-06-13 21:41:07 | Re: Making serial survive pg_dump |
Previous Message | Joe Conway | 2002-06-13 21:25:49 | Table Function (aka SRF) doc patch |