| 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: | Whole Thread | Raw Message | 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 |