From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Zhang Mingli <zmlpostgres(at)gmail(dot)com>, Surafel Temesgen <surafel3000(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: useless LIMIT_OPTION_DEFAULT |
Date: | 2023-12-16 16:42:28 |
Message-ID: | 202312161642.dzsvloromlfl@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2023-Dec-14, Tom Lane wrote:
> Zhang Mingli <zmlpostgres(at)gmail(dot)com> writes:
> > By reading the codes, I found that we process limit option as LIMIT_OPTION_WITH_TIES when using WITH TIES
> > and all others are LIMIT_OPTION_COUNT by commit 357889eb17bb9c9336c4f324ceb1651da616fe57.
> > And check actual limit node in limit_needed().
> > There is no need to maintain a useless default limit enum.
>
> I agree, that looks pretty useless. Our normal convention for
> representing not having any LIMIT clause would be to not create
> a SelectLimit node at all. I don't see why allowing a second
> representation is a good idea, especially when the code is not
> in fact doing that.
>
> git blame shows that this came in with 357889eb1. Alvaro,
> Surafel, do you want to argue for keeping things as-is?
I looked at the history of this. That enum member first appeared as a
result of your review at [1], and the accompanying code at that time did
use it a few times. The problem is that I later ([2]) proposed to rewrite
that code and remove most of the uses of that enum member, but failed to
remove it completely.
So, I think we're OK to remove it. I'm going to push Zhang's patch
soon unless there are objections.
[1] https://postgr.es/m/3277.1567722389@sss.pgh.pa.us
[2] https://postgr.es/m/20191125203442.GA30191@alvherre.pgsql
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Doing what he did amounts to sticking his fingers under the hood of the
implementation; if he gets his fingers burnt, it's his problem." (Tom Lane)
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-12-16 19:20:57 | Re: Show WAL write and fsync stats in pg_stat_io |
Previous Message | Alena Rybakina | 2023-12-16 15:41:27 | Re: [PoC] Reducing planning time when tables have many partitions |