From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org, Morus Walter <morus(dot)walter(at)experteer(dot)de> |
Subject: | Re: pg_dump versus SERIAL, round N |
Date: | 2006-08-19 16:25:26 |
Message-ID: | 28131.1156004726@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> On Sat, Aug 19, 2006 at 11:47:39AM -0400, Tom Lane wrote:
>> ALTER SEQUENCE foo_bar_seq SERIAL FOR foo.bar;
> I like it, and I imagine users will love it too. Only one question:
> will a sequence be limited to belonging to one table at a time, or
> could you use one sequence for multiple tables and use this to declare
> a dependancy on them all?
AFAICS it doesn't make sense to have the sequence "belong to" more than
one column at a time. Keep in mind that writing
DEFAULT nextval('foo_seq')
already causes the default expression to depend on foo_seq, so that if
you drop foo_seq the default will go away too (if CASCADE) or cause
an error (if RESTRICT). What's at stake here is whether dropping a
column should cause the sequence to go away, and I can't really see
that you'd want this to be true for more than one column. So my
proposal is for the ALTER SEQUENCE command to be defined as "remove
any existing internal dependency linking from the sequence to any
table column, then add one linking to this column".
Also, after thinking about the existing behavior of ALTER TABLE OWNER
(it tries to keep ownership of dependent sequences equal to the table's
ownership), we'd have to either abandon that or insist that you can
only link a sequence to a table having the same owner. So that's
another reason for not allowing a sequence to be linked to multiple
tables --- ALTER TABLE OWNER would inevitably create a mess.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-08-19 17:10:46 | Re: pg_dump versus SERIAL, round N |
Previous Message | Martijn van Oosterhout | 2006-08-19 16:03:14 | Re: pg_dump versus SERIAL, round N |