Re: Re: Re: Rules, views, sequences and returned values - Mailing list pgsql-general

From Doug McNaught
Subject Re: Re: Re: Rules, views, sequences and returned values
Date
Msg-id m3y9tw163d.fsf@belphigor.mcnaught.org
Whole thread Raw
In response to Rules, views, sequences and returned values  (DaVinci <bombadil@wanadoo.es>)
List pgsql-general
will trillich <will@serensoft.com> writes:

> On Fri, Mar 23, 2001 at 12:23:35PM -0500, Gregory Wood wrote:
> > > i'm sure there's a reason for this--
> > >
> > > psql=> select currval('mytable_afield_seq') ;
> > > ERROR:  mytable_afield_seq.currval is not yet defined in this session
> > >
> > > but i'll be darned if i can figure out what it is. (after one
> > > call to "nextval()" currval() works fine, of course.) someone hit
> > > me with a clue stick!
> >
> > currval() is the value last used by the backend, not by the database.
> > Meaning that you have to actually use the sequence before the backend has a
> > value to retrieve. That means either doing a nextval() or doing an INSERT
> > (which implicitly performs the nextval() ).
>
> <dense mode=on>
> seems like the backend (server?) would know the current value of
> a sequence, since it has to get it, then add one to it, to get
> the next one in line. if george inserts a record, i'd think that
> ringo would be able to see the current counter afterwards,
> independent of session...

Remember there are (potentially) multiple backends, one per client
connection.  Because of transaction isolation, there may be multiple
outstanding values of 'currval'.  There's no way to know the "real"
current value in your transaction unless you do 'nextval' (which
atomically gets the next free value of the sequence).

Does this make sense?  I probably didn't explain it very well.

-Doug

pgsql-general by date:

Previous
From: "Matt Friedman"
Date:
Subject: ~* OR LIKE?
Next
From: "Gregory Wood"
Date:
Subject: Re: Re: Re: Rules, views, sequences and returned values