Re: Using curr_val Wisely

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Andrew Snow" <als(at)fl(dot)net(dot)au>
Cc: "Jeff Waugh" <jdub(at)aphid(dot)net>, "Pgsql-General(at)Postgresql(dot) Org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Using curr_val Wisely
Date: 2000-07-12 17:22:57
Message-ID: 23599.963422577@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Andrew Snow" <als(at)fl(dot)net(dot)au> writes:
>> I'm using curr_val('blah_id_seq') in a transaction like so: (in
>> pseudo SQL)

> curr_val() returns the current value of the sequence, in the current
> transaction.

More precisely, currval() returns the same value returned by the most
recent nextval() on that sequence in the current backend --- transaction
boundaries don't matter AFAIR.

If you try currval() without ever having executed nextval() in the
current session, you will see this is so.

(I believe a setval() also causes currval() to become set, but that's
a special case that seldom matters.)

So you need not worry about other backends when using currval(). If you
have rules or triggers that can cause the sequence to get advanced, then
you could get confusing results if you forget these rules/triggers are
being fired.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jeff Waugh 2000-07-12 17:35:14 Re: Re: [INTERFACES] Re: Link to postgesql components
Previous Message Tom Lane 2000-07-12 17:03:50 Re: [NOVICE] newbie problem on creating table