Re: ORDER BY random() LIMIT 1 slowness
От | Jean-Luc Lachance |
---|---|
Тема | Re: ORDER BY random() LIMIT 1 slowness |
Дата | |
Msg-id | 3E00D8EE.89743B3A@nsd.ca обсуждение исходный текст |
Ответ на | Re: ORDER BY random() LIMIT 1 slowness ("scott.marlowe" <scott.marlowe@ihs.com>) |
Ответы |
Re: ORDER BY random() LIMIT 1 slowness
|
Список | 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 по дате отправления: