Kris Jurka <[EMAIL PROTECTED]> writes:
>> jurka=# create table t (c serial);
>> NOTICE: CREATE TABLE will create implicit sequence "t_c_seq" for serial
>> column "t.c"
>> CREATE TABLE
>> jurka=# select currval('t_c_seq');
>> currval
>> ---------
>> 1
>> (1 row)
>>
>> I would expect it to say that currval wasn't set like so:
... as indeed it did say, up till 8.2, so I concur this is a bug.
> Looks like any alter sequence command will do this. The serial case uses
> alter sequence owned by under the hood which exposes this. The problem is
> that altering the sequence puts it into the SeqTable cache list when it
> really shouldn't be.
It's not that it gets put in the cache, it's that read_info gets called
(setting elm->increment). I think we probably should clean this up by
creating a separate flag in that struct that explicitly says "currval is
valid", which would be set by nextval(), setval() (because historically
it's acted that way), and I guess ALTER SEQUENCE RESTART WITH (for
consistency with setval()).
Should any of the ALTER SEQUENCE options *reset* such a flag?
Offhand I don't see any...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
