>
> Out of curiosity, could you please tell me the concrete situations
> where you wanted to delete one of two identical records?
>
In my case, there is a table with known duplicates, and we would like to
delete all but the one with the lowest ctid, and then add a unique index to
the table which
Hello Greg,
On Fri, 17 Dec 2021 01:40:45 -0500
Greg Stark wrote:
> On Thu, 16 Dec 2021 at 22:18, Tom Lane wrote:
> >
> > * If the sort order is underspecified, or you omit ORDER BY
> > entirely, then it's not clear which rows will be operated on.
> > The LIMIT might stop after just some of the
On Thu, 16 Dec 2021 at 22:18, Tom Lane wrote:
>
> * If the sort order is underspecified, or you omit ORDER BY
> entirely, then it's not clear which rows will be operated on.
> The LIMIT might stop after just some of the rows in a peer
> group, and you can't predict which ones.
Meh, that never
On Thu, 16 Dec 2021 20:56:59 -0700
"David G. Johnston" wrote:
> On Thursday, December 16, 2021, Yugo NAGATA wrote:
>
> >
> > Also, here seem to be some use cases. For example,
> > - when you want to delete the specified number of rows from a table
> > that doesn't have a primary key and
of DELETE is basically same as SELECT statement,
> > so I think that we can also allow DELETE to use ORDER BY
> > and LIMIT/OFFSET.
>
> Indeed, this is technically possible, but we've rejected the idea
> before and I'm not aware of any reason to change our minds.
> The problem
On Thursday, December 16, 2021, Yugo NAGATA wrote:
>
> Also, here seem to be some use cases. For example,
> - when you want to delete the specified number of rows from a table
> that doesn't have a primary key and contains tuple duplicated.
Not our problem…use the tools correctly; there is
so allow DELETE to use ORDER BY
> and LIMIT/OFFSET.
Indeed, this is technically possible, but we've rejected the idea
before and I'm not aware of any reason to change our minds.
The problem is that a partial DELETE is not very deterministic
about which rows are deleted, and that does not seem lik
lly same as SELECT statement,
> so I think that we can also allow DELETE to use ORDER BY
> and LIMIT/OFFSET.
>
> Attached is the concept patch. This enables the following
> operations:
After post this, I noticed that there are several similar
proposals in past:
https://www.postg
Hello hackers,
We cannot use ORDER BY or LIMIT/OFFSET in the current
DELETE statement syntax, so all the row matching the
WHERE condition are deleted. However, the tuple retrieving
process of DELETE is basically same as SELECT statement,
so I think that we can also allow DELETE to use ORDER
