Re: Redundant Result node - Mailing list pgsql-hackers

From Richard Guo
Subject Re: Redundant Result node
Date
Msg-id CAMbWs49=CXNBjRWDcTv2gyu7iTHxMLsduMB_0iEudFdwfVsebA@mail.gmail.com
Whole thread Raw
In response to Re: Redundant Result node  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On Thu, Aug 22, 2024 at 8:03 PM David Rowley <dgrowleyml@gmail.com> wrote:
> On Thu, 22 Aug 2024 at 23:33, Peter Eisentraut <peter@eisentraut.org> wrote:
> > > I wonder if we need to invent a function to compare two PathTargets.
> >
> > Wouldn't the normal node equal() work?
>
> It might. I think has_volatile_expr might be missing a
> pg_node_attr(equal_ignore).

Yeah, maybe we can make the node equal() work for PathTarget.  We'll
need to remove the no_equal attribute in PathTarget.  I think we also
need to specify pg_node_attr(equal_ignore) for PathTarget.cost.

BTW, I'm wondering why we specify no_copy for PathTarget, while
meanwhile implementing a separate function copy_pathtarget() in
tlist.c to copy a PathTarget.  Can't we support copyObject() for
PathTarget?

Also the pg_node_attr(array_size(exprs)) attribute for
PathTarget.sortgrouprefs does not seem right to me.  In a lot of cases
sortgrouprefs would just be NULL.  Usually it is valid only for
upper-level Paths.  Hmm, maybe this is why we do not support
copyObject() for PathTarget?

Thanks
Richard



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: slru bank
Next
From: "David G. Johnston"
Date:
Subject: Re: slru bank