pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix deparsing FETCH FIRST <expr> ROWS WITH TIES 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix deparsing FETCH FIRST <expr> ROWS WITH TIES @ 2025-05-19 15:52 Heikki Linnakangas <heikki.linnakangas@iki.fi> 0 siblings, 0 replies; 6+ messages in thread From: Heikki Linnakangas @ 2025-05-19 15:52 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix deparsing FETCH FIRST <expr> ROWS WITH TIES @ 2025-05-19 15:52 Heikki Linnakangas <heikki.linnakangas@iki.fi> 0 siblings, 0 replies; 6+ messages in thread From: Heikki Linnakangas @ 2025-05-19 15:52 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/54c05292b1ffc8d7ad9305d224225161e4d3d412 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix deparsing FETCH FIRST <expr> ROWS WITH TIES @ 2025-05-19 15:52 Heikki Linnakangas <heikki.linnakangas@iki.fi> 0 siblings, 0 replies; 6+ messages in thread From: Heikki Linnakangas @ 2025-05-19 15:52 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/72fe74ca533375fa04264f976d4c4971c6804dce 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix deparsing FETCH FIRST <expr> ROWS WITH TIES @ 2025-05-19 15:52 Heikki Linnakangas <heikki.linnakangas@iki.fi> 0 siblings, 0 replies; 6+ messages in thread From: Heikki Linnakangas @ 2025-05-19 15:52 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 ------ master Details ------- https://git.postgresql.org/pg/commitdiff/29f7ce6fe78e3f8d520764b5870453d791a3ca65 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix deparsing FETCH FIRST <expr> ROWS WITH TIES @ 2025-05-19 15:52 Heikki Linnakangas <heikki.linnakangas@iki.fi> 0 siblings, 0 replies; 6+ messages in thread From: Heikki Linnakangas @ 2025-05-19 15:52 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/0420b24fee5e6483e1aa032f75edf340c14d4109 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix deparsing FETCH FIRST <expr> ROWS WITH TIES @ 2025-05-19 15:52 Heikki Linnakangas <heikki.linnakangas@iki.fi> 0 siblings, 0 replies; 6+ messages in thread From: Heikki Linnakangas @ 2025-05-19 15:52 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix deparsing FETCH FIRST <expr> ROWS WITH TIES In the grammar, <expr> is a c_expr, which accepts only a limited set of simple constants and 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_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/7ee00918f7cdd76c8c1120f019288dd71d48f42d 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2025-05-19 15:52 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-05-19 15:52 pgsql: Fix deparsing FETCH FIRST <expr> ROWS WITH TIES Heikki Linnakangas <heikki.linnakangas@iki.fi> 2025-05-19 15:52 pgsql: Fix deparsing FETCH FIRST <expr> ROWS WITH TIES Heikki Linnakangas <heikki.linnakangas@iki.fi> 2025-05-19 15:52 pgsql: Fix deparsing FETCH FIRST <expr> ROWS WITH TIES Heikki Linnakangas <heikki.linnakangas@iki.fi> 2025-05-19 15:52 pgsql: Fix deparsing FETCH FIRST <expr> ROWS WITH TIES Heikki Linnakangas <heikki.linnakangas@iki.fi> 2025-05-19 15:52 pgsql: Fix deparsing FETCH FIRST <expr> ROWS WITH TIES Heikki Linnakangas <heikki.linnakangas@iki.fi> 2025-05-19 15:52 pgsql: Fix deparsing FETCH FIRST <expr> ROWS WITH TIES Heikki Linnakangas <heikki.linnakangas@iki.fi>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox