Re: Invalid query generated by postgres_fdw with UNION ALL and ORDER BY
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Michał Kłeczek <michal@kleczek.org>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-03-07T11:08:42Z
Lists: pgsql-hackers
Attachments
- postgres_fdw_order_by_const_fix.patch (text/plain) patch
- demo_of_postgres_fdw_order_by_const_bug.sql (application/octet-stream)
On Thu, 7 Mar 2024 at 19:09, Michał Kłeczek <michal@kleczek.org> wrote: > > The following query: > > SELECT * FROM ( > SELECT 2023 AS year, * FROM remote_table_1 > UNION ALL > SELECT 2022 AS year, * FROM remote_table_2 > ) > ORDER BY year DESC; > > yields the following remote query: > > SELECT [columns] FROM remote_table_1 ORDER BY 2023 DESC > > and subsequently fails remote execution. > > > Not really sure where the problem is - the planner or postgres_fdw. > I guess it is postgres_fdw not filtering out ordering keys. Interesting. I've attached a self-contained recreator for the casual passerby. I think the fix should go in appendOrderByClause(). It's at that point we look for the EquivalenceMember for the relation and can easily discover if the em_expr is a Const. I think we can safely just skip doing any ORDER BY <const> stuff and not worry about if the literal format of the const will appear as a reference to an ordinal column position in the ORDER BY clause. Something like the attached patch I think should work. I wonder if we need a test... David
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