Re: ORDER BY random() LIMIT 1 slowness

Have another suggestion then -- add lastval().

We would have:

nextval() transaction safe
currval() transaction safe (nextval() must be called first)
lastval() transaction unsafe

JLL


"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
> >