Re: ORDER BY random() LIMIT 1 slowness - Mailing list pgsql-general

From Jean-Luc Lachance
Subject Re: ORDER BY random() LIMIT 1 slowness
Date
Msg-id 3E00D8EE.89743B3A@nsd.ca
Whole thread Raw
In response to Re: ORDER BY random() LIMIT 1 slowness  ("scott.marlowe" <scott.marlowe@ihs.com>)
Responses Re: ORDER BY random() LIMIT 1 slowness
List pgsql-general
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.

pgsql-general by date:

Previous
From: "scott.marlowe"
Date:
Subject: Re: To many connections Error
Next
From: Joe Conway
Date:
Subject: Re: Measuring CPU time use? (Another stupid question)