From: Tom Lane <tgl@sss.pgh.pa.us>
To: Zhang Mingli <zmlpostgres@gmail.com>
cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
        Surafel Temesgen <surafel3000@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: useless LIMIT_OPTION_DEFAULT
In-reply-to: <59d61a1a-3858-475a-964f-24468c97cc67@Spark>
References: <b4f097ce-6422-49d7-888a-2e0a7a18f5f2@Spark> <59d61a1a-3858-475a-964f-24468c97cc67@Spark>
Comments: In-reply-to Zhang Mingli <zmlpostgres@gmail.com>
	message dated "Thu, 14 Dec 2023 09:17:33 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <2828940.1702590425.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 14 Dec 2023 16:47:05 -0500
Message-ID: <2828941.1702590425@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/2828941.1702590425%40sss.pgh.pa.us>
Precedence: bulk

Zhang Mingli <zmlpostgres@gmail.com> writes:
> By reading the codes, I found that we process limit option as LIMIT_OPTI=
ON_WITH_TIES when using WITH TIES
> and all others are LIMIT_OPTION_COUNT by=C2=A0=C2=A0commit 357889eb17bb9=
c9336c4f324ceb1651da616fe57.
> 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?

			regards, tom lane