Thread: Sequence behaviour.
Why is the following like it is? I would think that nextval would return 2 in both instances, am I missing something here? :) Thanks! binary_data=# create sequence test; CREATE binary_data=# select nextval('test'); NOTICE: test.nextval: sequence was re-creatednextval --------- 1 (1 row) binary_data=# select setval('test', 1);setval -------- 1 (1 row) binary_data=# select nextval('test');nextval --------- 2 (1 row) binary_data=#
Grant <grant@conprojan.com.au> writes: > Why is the following like it is? I would think that nextval would return 2 > in both instances, am I missing something here? :) Thanks! > binary_data=# create sequence test; > CREATE > binary_data=# select nextval('test'); > NOTICE: test.nextval: sequence was re-created Um, how did you get that NOTICE? I don't see it. Anyway, the answer to your question is that there's another bit of state in a sequence: the is_called flag is initially false and is set true during the first-ever nextval(). This allows nextval to deliver the specified start value on the first call, rather than the one after that. In 7.1 setval() takes an optional third argument to reset the value of is_called... regards, tom lane
> > binary_data=# create sequence test; > > CREATE > > binary_data=# select nextval('test'); > > NOTICE: test.nextval: sequence was re-created > > Um, how did you get that NOTICE? I don't see it. This is version 7.0.3. I deleted the sequence first. > Anyway, the answer to your question is that there's another bit of > state in a sequence: the is_called flag is initially false and is > set true during the first-ever nextval(). This allows nextval to > deliver the specified start value on the first call, rather than > the one after that. In 7.1 setval() takes an optional third > argument to reset the value of is_called... Ok. Still a bit weird to me anyhow. Thanks.