From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Cristian Prieto <cristian(at)clickdiario(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Support for Limit in Update, Insert... |
Date: | 2005-09-09 02:49:25 |
Message-ID: | 28935.1126234165@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> This has been discussed before, and rejected. Please see the archives.
For SELECT, both LIMIT and OFFSET are only well-defined in the presence
of an ORDER BY clause. (One could argue that we should reject them when
no ORDER BY, but given that the database isn't getting changed as a side
effect, that's probably too anal-retentive. When the database *is*
going to be changed, however, I for one like well-defined results.)
If this proposal included adding an ORDER BY to UPDATE/DELETE, then it
would at least be logically consistent. I have not seen the use-case
for it though. In any case you can usually get the equivalent result
with something like
UPDATE foo SET ...
WHERE pkey IN (SELECT pkey FROM foo ORDER BY ... LIMIT ...);
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Poul Jensen | 2005-09-09 03:58:55 | SQL - planet redundant data |
Previous Message | Leonid Safronie | 2005-09-09 02:46:38 | Cost based SELECT/UPDATE |