On Fri, Mar 8, 2024 at 7:43 AM David Rowley wrote:
> On Fri, 8 Mar 2024 at 00:54, Ashutosh Bapat
> wrote:
> >
> > On Thu, Mar 7, 2024 at 4:39 PM David Rowley
> wrote:
> >> I think the fix should go in appendOrderByClause(). It's at that
> >> point we look for the EquivalenceMember for the
On Fri, 8 Mar 2024 at 23:14, Richard Guo wrote:
> 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
On Fri, Mar 8, 2024 at 10:13 AM David Rowley 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
On Fri, 8 Mar 2024 at 00:54, Ashutosh Bapat
wrote:
>
> On Thu, Mar 7, 2024 at 4:39 PM David Rowley wrote:
>> 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
On Thu, Mar 7, 2024 at 4:39 PM David Rowley wrote:
> On Thu, 7 Mar 2024 at 19:09, Michał Kłeczek 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
On Thu, 7 Mar 2024 at 19:09, Michał Kłeczek 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
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.
