From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Michał Kłeczek <michal(at)kleczek(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Invalid query generated by postgres_fdw with UNION ALL and ORDER BY |
Date: | 2024-03-07 11:54:40 |
Message-ID: | CAExHW5taz6hX05P55_S1cbx+P5CcNN21rD7oLY5iXJcShrAbaQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 7, 2024 at 4:39 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> On Thu, 7 Mar 2024 at 19:09, Michał Kłeczek <michal(at)kleczek(dot)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.
>
deparseSortGroupClause() calls deparseConst() with showtype = 1.
appendOrderByClause() may want to do something similar for consistency. Or
remove it from deparseSortGroupClause() as well?
>
> Something like the attached patch I think should work.
>
> I wonder if we need a test...
>
Yes.
--
Best Wishes,
Ashutosh Bapat
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2024-03-07 12:06:08 | Re: remaining sql/json patches |
Previous Message | Tomas Vondra | 2024-03-07 11:44:41 | Re: Shared detoast Datum proposal |