Re: ORDER BY random() LIMIT 1 slowness

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(at)postgresql(dot)org
>