Skip site navigation (1) Skip section navigation (2)

Re: pg_dump bug in 7.3.9 with sequences

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>,Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump bug in 7.3.9 with sequences
Date: 2005-02-03 19:47:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
>>>pg_dump will just emit "create table t1 (f1 serial)" with no hint that
>>>the sequence ought to be set to CYCLE mode.  I'm not sure about an
>>>appropriate fix offhand --- we can't very well use ALTER SEQUENCE in
>>>just this way in the dump, because of the risk of the sequence name
>>>being possibly different at reload.  (Come to think of it, we are not
>>>very good about propagating GRANTs on the sequence either, because of
>>>the same risk.)
>>I suggest some time ago an alternative syntax for ALTER SEQUENCE.
> Could work, but we'd have to support it for GRANT/REVOKE too, which is
> starting to get ugly.  (Now, if we went down the recently suggested path
> of allowing sub-selects to compute the target object names for all
> utility statements, this would fall out nicely.  But having a special
> case in ALTER SEQUENCE and GRANT seems pretty wart-ish.)
> Another alternative I was thinking about in the shower this morning is
> to have pg_dump treat the sequence as an independent object.  So the
> dump script would CREATE it, set parameters and GRANTs, just the same as
> for a plain sequence, and then do a magic ALTER TABLE command that
> attaches it to the serial column, which the script would initially
> declare as a plain integer or bigint.  This seems relatively clean to me
> because it is in the same spirit as the way we handle index constraints
> now: they aren't in the initial table definition but get added by ALTER
> at a suitable time.  However the "magic command" is a big wart of its
> own, no doubt.  It's not just an ALTER COLUMN TYPE command because you'd
> need to be able to specify the name of the sequence to attach.  It's not
> just an ALTER SET DEFAULT, either, because it would have special
> side-effects on pg_depend.

Wouldn't a lot of this be solved (I know I am over simplyfing) by making
serial a real type? E.g; if you have type serial it is type serial not
type integer with a default of nextval('sequence'). Thus if I have an
integer with a default of (anything really) that is how it is restore.
If I have a serial, it is a serial and is restored in that manner.

Using this idea, you would get the can't alter default of a serial but
also the ability to alter the default if it is NOT a serial but will
still auto-increment.


Joshua D. Drake

> 			regards, tom lane
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)

Command Prompt, Inc., your source for PostgreSQL replication,
professional support, programming, managed services, shared
and dedicated hosting. Home of the Open Source Projects plPHP,
plPerlNG, pgManage,  and pgPHPtoolkit.
Contact us now at: +1-503-667-4564 -

Attachment: jd.vcf
Description: text/x-vcard (640 bytes)

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2005-02-03 20:32:46
Subject: Re: pg_dump bug in 7.3.9 with sequences
Previous:From: Pavan Kumar Chowdary PDate: 2005-02-03 19:39:54
Subject: postgresql documentation for developers

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group