Feedback-ID: ia2694551:Fastmail
Date: Thu, 16 May 2024 18:47:21 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Japin Li <japinli@hotmail.com>
Cc: Etsuro Fujita <etsuro.fujita@gmail.com>, onderkalaci@gmail.com,
	pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption
Message-ID: <202405161647.dj7lw4asvfpu@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <ME3P282MB3166558F8BC9798D4872F915B6ED2@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM>
Archived-At: 
 <https://www.postgresql.org/message-id/202405161647.dj7lw4asvfpu%40alvherre.pgsql>
Precedence: bulk

On 2024-May-17, Japin Li wrote:

> After some dig in, I find transformLimitClause() has the following comments:
> 
>  * Note: as of Postgres 8.2, LIMIT expressions are expected to yield int8,
>  * rather than int4 as before.
> 
> So the deparseConst() append '::bigint' typecast, same as get_rule_expr().

Hmm, probably the answer is not to use deparseExpr in
appendLimitClause() then.  I mean, AFAICS this is a postgres_fdw
problem, not a core parser problem.

Not sure if this is workable, but maybe test if the value is a constant,
and use FETCH FIRST if so, otherwise fall back to using LIMIT.  (It's
not clear if this would handle FETCH FIRST +123123123123 ROWS WITH TIES
correctly though -- worth checking).


Oh, I see we never got back to adding FETCH FIRST / PERCENT.  We had a
patch seemingly almost ready for that ...

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/