agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: postgres_fdw: don't push down non-relabeling ArrayCoerceExpr 2+ messages / 1 participants [nested] [flat]
* pgsql: postgres_fdw: don't push down non-relabeling ArrayCoerceExpr @ 2026-07-14 22:59 Alexander Korotkov <akorotkov@postgresql.org> 0 siblings, 0 replies; 2+ messages in thread From: Alexander Korotkov @ 2026-07-14 22:59 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org postgres_fdw: don't push down non-relabeling ArrayCoerceExpr Commit 62c3b4cd9ddc taught postgres_fdw to push down ArrayCoerceExpr, but foreign_expr_walker() only recursed into the input array expression and never examined elemexpr, the per-element conversion that gives the coercion its semantics. deparseArrayCoerceExpr() then shipped a bare "arg::resulttype" cast, or nothing at all for an implicit-format coercion, leaving the remote server to re-resolve the element conversion against its own catalogs and session state. This produced wrong results or remote errors whenever the element conversion was not a plain relabeling, and it was inconsistent with how postgres_fdw treats the equivalent scalar coercions. An ArrayCoerceExpr was shipped even when its elemexpr was a cast function (whose shippability was never checked), a CoerceViaIO (e.g. float8out or byteaout, which depend on extra_float_digits / bytea_output that postgres_fdw sets differently on the remote session), or a CoerceToDomain (which pushes domain enforcement to the remote catalog). By contrast, a scalar CoerceViaIO is never shipped, and a scalar cast function is shipped only when it is shippable. Restrict pushdown to element coercions that are a plain relabeling, that is, elemexpr is a RelabelType or a bare CaseTestExpr. Any other element coercion is now evaluated locally. This keeps the common binary-coercible case pushed down, including "col = ANY($1)" with a varchar[]-to-text[] relabeling, which is the case 62c3b4cd9ddc set out to optimize. Pushing down shippable element cast functions, to reach parity with the scalar case, is left out here for simplicity. Reported-by: Noah Misch <noah@leadboat.com> Discussion: https://postgr.es/m/20260711024234.43.noahmisch%40microsoft.com Backpatch-through: 19 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/e5354459383536a9644c4b0c8c26df0fcacae5f3 Modified Files -------------- contrib/postgres_fdw/deparse.c | 20 +++++++ contrib/postgres_fdw/expected/postgres_fdw.out | 75 ++++++++++++++++++++++++++ contrib/postgres_fdw/sql/postgres_fdw.sql | 35 ++++++++++++ 3 files changed, 130 insertions(+) ^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: postgres_fdw: don't push down non-relabeling ArrayCoerceExpr @ 2026-07-14 22:59 Alexander Korotkov <akorotkov@postgresql.org> 0 siblings, 0 replies; 2+ messages in thread From: Alexander Korotkov @ 2026-07-14 22:59 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org postgres_fdw: don't push down non-relabeling ArrayCoerceExpr Commit 62c3b4cd9ddc taught postgres_fdw to push down ArrayCoerceExpr, but foreign_expr_walker() only recursed into the input array expression and never examined elemexpr, the per-element conversion that gives the coercion its semantics. deparseArrayCoerceExpr() then shipped a bare "arg::resulttype" cast, or nothing at all for an implicit-format coercion, leaving the remote server to re-resolve the element conversion against its own catalogs and session state. This produced wrong results or remote errors whenever the element conversion was not a plain relabeling, and it was inconsistent with how postgres_fdw treats the equivalent scalar coercions. An ArrayCoerceExpr was shipped even when its elemexpr was a cast function (whose shippability was never checked), a CoerceViaIO (e.g. float8out or byteaout, which depend on extra_float_digits / bytea_output that postgres_fdw sets differently on the remote session), or a CoerceToDomain (which pushes domain enforcement to the remote catalog). By contrast, a scalar CoerceViaIO is never shipped, and a scalar cast function is shipped only when it is shippable. Restrict pushdown to element coercions that are a plain relabeling, that is, elemexpr is a RelabelType or a bare CaseTestExpr. Any other element coercion is now evaluated locally. This keeps the common binary-coercible case pushed down, including "col = ANY($1)" with a varchar[]-to-text[] relabeling, which is the case 62c3b4cd9ddc set out to optimize. Pushing down shippable element cast functions, to reach parity with the scalar case, is left out here for simplicity. Reported-by: Noah Misch <noah@leadboat.com> Discussion: https://postgr.es/m/20260711024234.43.noahmisch%40microsoft.com Backpatch-through: 19 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/2349b106b6661c084dc1171654146c730ecb048f Modified Files -------------- contrib/postgres_fdw/deparse.c | 20 +++++++ contrib/postgres_fdw/expected/postgres_fdw.out | 75 ++++++++++++++++++++++++++ contrib/postgres_fdw/sql/postgres_fdw.sql | 35 ++++++++++++ 3 files changed, 130 insertions(+) ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-07-14 22:59 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-07-14 22:59 pgsql: postgres_fdw: don't push down non-relabeling ArrayCoerceExpr Alexander Korotkov <akorotkov@postgresql.org> 2026-07-14 22:59 pgsql: postgres_fdw: don't push down non-relabeling ArrayCoerceExpr Alexander Korotkov <akorotkov@postgresql.org>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox