From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Zoltan Boszormenyi <zb(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCHES] TRUNCATE TABLE with IDENTITY |
Date: | 2008-05-17 00:15:37 |
Message-ID: | 4346.1210983337@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
I wrote:
> One interesting point here is that the patch as submitted allowed
> ALTER SEQUENCE MINVALUE/MAXVALUE to be used to set a sequence range
> that the original START value was outside of. This would result in
> a failure at ALTER SEQUENCE RESTART. Since, as stated above, we
> really don't want that happening during TRUNCATE, I adjusted the
> patch to make such an ALTER SEQUENCE fail. This is at least potentially
> an incompatible change: command sequences that used to be legal could
> now fail. I doubt it's very likely to bite anyone in practice, though.
It occurs to me that we could define
ALTER SEQUENCE s START WITH x
(which is syntactically legal, but rejected by sequence.c at the moment)
as updating the stored start_value and thus affecting what future
ALTER SEQUENCE RESTART commands will do. Right now there is simply
no way to change start_value after sequence creation, which is pretty
strange considering we let you change every other sequence parameter.
It would also provide a way out for anyone who does want to change the
minval/maxval as sketched above.
I think this is about a ten-line change as far as the code goes...
any objections?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2008-05-17 01:35:52 | Re: [HACKERS] TRUNCATE TABLE with IDENTITY |
Previous Message | Andrew Chernow | 2008-05-17 00:00:07 | Re: libpq object hooks |
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2008-05-17 01:35:52 | Re: [HACKERS] TRUNCATE TABLE with IDENTITY |
Previous Message | Andrew Chernow | 2008-05-17 00:00:07 | Re: libpq object hooks |