Re: Implementation of LIMIT on DELETE and UPDATE statements (rel to 7.2.1)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Implementation of LIMIT on DELETE and UPDATE statements (rel to 7.2.1)
Дата
Msg-id 14335.1032750653@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Implementation of LIMIT on DELETE and UPDATE statements (rel to 7.2.1)  (Alvaro Herrera <alvherre@atentus.com>)
Ответы Re: Implementation of LIMIT on DELETE and UPDATE statements  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Implementation of LIMIT on DELETE and UPDATE statements (rel to 7.2.1)  (srb@cuci.nl (Stephen R. van den Berg))
Список pgsql-patches
> srb@cuci.nl (Stephen R. van den Berg) escribi�:
>> Incidentally, using a SELECT without an ORDER BY but with a LIMIT is
>> documented to give unpredictable results, yet users are expected cope with
>> this fact, but are expected to have problems with a similar fact in
>> an UPDATE or DELETE statement?

Well, IMHO there's a big difference in documented unpredictable output
from a documented-unpredictable query, as opposed to
documented-unpredictable changes in the database state.  There is not
a lot of use for the latter AFAICS.

Alvaro Herrera <alvherre@atentus.com> writes:
> as I already said, the feature has some value with the ORDER BY added,
> and the LIMIT/OFFSET thing expanded to allow expressions (this last part
> is in TODO).

I'd have more confidence in the usefulness of the idea if it included
ORDER BY to make the LIMIT predictable.  But before you run off and
implement that: does MySQL support such a thing?  If not, the argument
of improving compatibility still doesn't hold any water...

            regards, tom lane

В списке pgsql-patches по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Memory Errors...
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Implementation of LIMIT on DELETE and UPDATE statements