Re: Invalid query generated by postgres_fdw with UNION ALL and ORDER BY
Richard Guo <guofenglinux@gmail.com>
From: Richard Guo <guofenglinux@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Michał Kłeczek <michal@kleczek.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-03-08T10:14:00Z
Lists: pgsql-hackers
On Fri, Mar 8, 2024 at 10:13 AM David Rowley <dgrowleyml@gmail.com> wrote: > The fix could also be to use deparseConst() in appendOrderByClause() > and have that handle Const EquivalenceMember instead. I'd rather just > skip them. To me, that seems less risky than ensuring deparseConst() > handles all Const types correctly. I've looked at this patch a bit. I once wondered why we don't check pathkey->pk_eclass->ec_has_const with EC_MUST_BE_REDUNDANT to see if the pathkey is not needed. Then I realized that a child member would not be marked as constant even if the child expr is a Const, as explained in add_child_rel_equivalences(). BTW, I wonder if it is possible that we have a pseudoconstant expression that is not of type Const. In such cases we would need to check 'bms_is_empty(pull_varnos(em_expr))' instead of 'IsA(em_expr, Const)'. However, I'm unable to think of such an expression in this context. The patch looks good to me otherwise. Thanks Richard
Commits
-
Fix deparsing of Consts in postgres_fdw ORDER BY
- 9301e0f416d1 12.19 landed
- 20b85b3da6f8 13.15 landed
- 628c3f2e17fe 14.12 landed
- ab64b275ad8f 15.7 landed
- 6a9e2cb2b457 16.3 landed
- c399248b3b44 17.0 landed