Skip site navigation (1) Skip section navigation (2)

Re: creating a table with a serial column sets currval

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: creating a table with a serial column sets currval
Date: 2007-10-18 20:48:45
Message-ID: 28583.1192740525@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Kris Jurka <books(at)ejurka(dot)com> 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

In response to

Responses

pgsql-bugs by date

Next:From: Oliver JowettDate: 2007-10-18 20:59:57
Subject: Re: [JDBC] Re: 'on insert do instead' rule with a where clause responds 'INSERT 0 0'
Previous:From: Kris JurkaDate: 2007-10-18 20:23:59
Subject: Re: creating a table with a serial column sets currval

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group