On Thu, 18 Oct 2007, Tom Lane wrote:
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()).
Personally I think setval should only set validCurrval and the last_value
if iscalled = true. If is_called = false I think it should retain the
previous last_value if any until the next nextval call.
jurka=# create sequence s;
CREATE SEQUENCE
jurka=# select nextval('s');
nextval
---------
1
(1 row)
jurka=# select setval('s',5, false);
setval
--------
5
(1 row)
jurka=# select currval('s');
currval
---------
5
(1 row)
Should return 1 instead of 5.
Kris Jurka
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
