Re: Properly pathify the union planner - Mailing list pgsql-hackers

From Richard Guo
Subject Re: Properly pathify the union planner
Date
Msg-id CAMbWs49gWbhSVdX0kT2x5XGKmP5OZerp6VhEA-hM4BvLHxKaqQ@mail.gmail.com
Whole thread Raw
In response to Re: Properly pathify the union planner  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Properly pathify the union planner
List pgsql-hackers

On Wed, Mar 27, 2024 at 6:23 AM David Rowley <dgrowleyml@gmail.com> wrote:
Because this field is set, it plans the CTE thinking it's a UNION
child and breaks when it can't find a SortGroupClause for the CTE's
target list item.

Right.  The problem here is that we mistakenly think that the CTE query
is a subquery for the set operation and thus store the SetOperationStmt
in its qp_extra.  Currently the code for the check is:

   /*
    * Check if we're a subquery for a set operation.  If we are, store
    * the SetOperationStmt in qp_extra.
    */
   if (root->parent_root != NULL &&
       root->parent_root->parse->setOperations != NULL &&
       IsA(root->parent_root->parse->setOperations, SetOperationStmt))
       qp_extra.setop =
           (SetOperationStmt *) root->parent_root->parse->setOperations;
   else
       qp_extra.setop = NULL;

This check cannot tell if the subquery is for a set operation or a CTE,
because its parent might have setOperations set in both cases.  Hmm, is
there any way to differentiate between the two?

Thanks
Richard

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: recovery modules
Next
From: shveta malik
Date:
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation