Hi,
If you need the last gobal value of the sequence just query the
sequence directly.
select last_value, increment_by from xyz_seq;
last_value | increment_by
------------+--------------
355 | 1
(1 row)
or just
select last_value from xyz_seq;
last_value
------------
355
(1 row)
I think that sequences are great in postgresql after going from oracle
to mysql to postgresql.
Regards,
Simon
scott.marlowe wrote:
> But the problem is that we'd immediately be innundated on the
> pgsql-general list by people who were using currval() in an unsafe way
> but didn't know it until they went into production and watched their
> application develop serious issues. I.e. they have a right to expect
> the sequence functions to operate in a transaction safe manner. It's
> not something that is likely to ever change, which is, imnsho, a good
> thing.
>
> On Wed, 18 Dec 2002, Jean-Luc Lachance wrote:
>
>
>
>> Scott,
>>
>> I understand it all.
>>
>> If a programmer understand that currval() return the last_(used)_value
>> and did not himself call nextval() he should be aware of the caveat.
>>
>> I did not want to make a big fuss of it. I will just use select
>> last_value myself since I am already aware of the caveat. :)
>>
>> JLL
>>
>>
>> "scott.marlowe" wrote:
>>
>>
>>> On Wed, 18 Dec 2002, Jean-Luc Lachance wrote:
>>>
>>>
>>>
>>>> Alvara,
>>>>
>>>> But instead of returning an error, currval() should return
>>>> last_value if
>>>> nextval() was not called (with all the caveat of couse). I think it
>>>> would be more usefull that way.
>>>>
>>>
>>> no, that would be like walking around with a gun pointed at your
>>> foot, to
>>> quote Tom Lane.
>>>
>>> See my post on transactions and such. Remember that everything in
>>> Postgresql is designed to make transactions safe. currval working
>>> without
>>> a nextval or setval before it is dangerous in the exterme to
>>> transactions.
>>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>>
>>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
>
>
