From: | Jean-Luc Lachance <jllachan(at)nsd(dot)ca> |
---|---|
To: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, "SZUCS =?iso-8859-1?Q?G=E1bor?=" <surrano(at)mailbox(dot)hu>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: ORDER BY random() LIMIT 1 slowness |
Date: | 2002-12-18 20:22:06 |
Message-ID: | 3E00D8EE.89743B3A@nsd.ca |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Jessica Blank | 2002-12-18 20:30:22 | Re: Measuring CPU time use? (Another stupid question) |
Previous Message | scott.marlowe | 2002-12-18 20:13:43 | Re: To many connections Error |