| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi> |
|---|---|
| To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | pgsql: Fix deparsing FETCH FIRST <expr> ROWS WITH TIES |
| Date: | 2025-05-19 15:52:20 |
| Message-ID: | E1uH2mp-002PpA-33@gemulon.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
Fix deparsing FETCH FIRST <expr> ROWS WITH TIES
In the grammar, <expr> is a c_expr, which accepts only a limited set
of integer literals and simple expressions without parens. The
deparsing logic didn't quite match the grammar rule, and failed to use
parens e.g. for "5::bigint".
To fix, always surround the expression with parens. Would be nice to
omit the parens in simple cases, but unfortunately it's non-trivial to
detect such simple cases. Even if the expression is a simple literal
123 in the original query, after parse analysis it becomes a FuncExpr
with COERCE_IMPLICIT_CAST rather than a simple Const.
Reported-by: yonghao lee
Backpatch-through: 13
Discussion: https://www.postgresql.org/message-id/18929-077d6b7093b176e2@postgresql.org
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/92a9ba3b96c2bb483d53096fbf223501d0b327a2
Modified Files
--------------
src/backend/utils/adt/ruleutils.c | 10 ++++++++++
src/test/regress/expected/limit.out | 20 +++++++++++++++++---
src/test/regress/sql/limit.sql | 5 ++++-
3 files changed, 31 insertions(+), 4 deletions(-)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2025-05-20 01:08:41 | pgsql: aio: Fix possible state confusions due to interrupt processing |
| Previous Message | Amit Kapila | 2025-05-19 07:02:00 | pgsql: Don't retreat slot's confirmed_flush LSN. |