From: | srb(at)cuci(dot)nl (Stephen R(dot) van den Berg) |
---|---|
To: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Implementation of LIMIT on DELETE and UPDATE statements (rel to 7.2.1) |
Date: | 2002-09-21 23:19:24 |
Message-ID: | 20020921231924.GB11536@cuci.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Stephen R. van den Berg wrote:
>Tom Lane wrote:
>>Then use ctid.
>Hmmm, I didn't know about ctid. It does seem to allow me to distinguish
>values. It will require a SELECT followed by a DELETE or UPDATE though
>AFAICS. But I agree that it seems to solve my problem.
Funny, actually.
I just changed my application from doing a:
DELETE FROM a WHERE b=3 LIMIT 1;
to:
DELETE FROM a WHERE ctid=(SELECT ctid FROM a WHERE b=3 LIMIT 1);
It works.
Actually, it works *identically*, i.e. the actual row deleted is
just as randomly chosen as in the DELETE with LIMIT case.
The first version looks cleaner to me (and better understandable) though.
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?
Somehow the argumentation is not conclusive.
--
Sincerely, srb(at)cuci(dot)nl
Stephen R. van den Berg (AKA BuGless).
Do more than anyone expects, and pretty soon everyone will expect more.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2002-09-21 23:35:03 | Re: Implementation of LIMIT on DELETE and UPDATE statements (rel to 7.2.1) |
Previous Message | Stephen R. van den Berg | 2002-09-21 22:46:25 | Re: Implementation of LIMIT on DELETE and UPDATE statements (rel to 7.2.1) |