pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedFrom: Tom Lane <tgl@sss.pgh.pa.us>
To: shihao zhong <zhong950419@gmail.com>
Cc: feasiblechart@gmail.com, David Rowley <dgrowleyml@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19742: `INTERSECT` under a `UNION ALL` with an empty arm fails with "could not find pathkey item t"
Date: Mon, 05 Oct 2026 13:39:06 -0400
Message-ID: <1087303.1791221946@sss.pgh.pa.us> (raw)
In-Reply-To: <CAGRkXqTK91Bca0Z7+d7CSENAM08LsqhNT8t5KAFRCEY0NzTsUQ@mail.gmail.com>
References: <19742-dc403ca277cad1d3@postgresql.org>
<261146.1791064428@sss.pgh.pa.us>
<CAGRkXqTK91Bca0Z7+d7CSENAM08LsqhNT8t5KAFRCEY0NzTsUQ@mail.gmail.com>
shihao zhong <zhong950419@gmail.com> writes:
> This is the small fix, meant for 19 and master.
Sorry for having overlooked this email earlier. It's substantially
the same fix I came up with, so I credited you as co-author.
I've pushed these two fixes and marked the open item as done.
> I think a better fix would make the pathkeys right in both places,
> so the Append can keep them. I can work on that for master if you
> like.
If you're interested in working on a long-term fix, I think the path
forward ought to be to get rid of these "varno 0" Vars in favor of
using ordinary Vars that reference real RangeTblEntrys. Right now,
a Query level that represents a set-op nest only has RTE_SUBQUERY
RTEs for the leaf queries. I'm imagining inventing a new RTEKind,
say RTE_SETOP, and building one of those for each set operation
in the nest. Then the Vars representing the output columns of that
set operation could carry that RTE's index, and everything gets a
lot less magic. I'm not sure that there would be any large reduction
in total lines of code, but it'd be cleaner, and there are some things
such as tlist width estimation that would work better.
While we could move much of what's in SetOperationStmt into such
RTEs, I'd be inclined not to, because additional fields in
RangeTblEntry would just be bloat for non-SETOP RTEs. So my
druthers would be to add no new fields to RangeTblEntry, just
re-use whatever ones are there that are useful. SetOperationStmt
probably needs to gain a field for the index of the associated
RTE, though.
IIRC, there are XXX comments in prepunion.c whining about how
building the setop tlists ought to be done at parse time, so
that's something we could look into at the same time, or as a
follow-on patch.
regards, tom lane
view thread (14+ messages) latest in thread
Message-ID: <1087303.1791221946@sss.pgh.pa.us>
Permalink: ../1087303.1791221946@sss.pgh.pa.us/
Also on: postgresql.org/message-id/1087303.1791221946@sss.pgh.pa.us
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, zhong950419@gmail.com, dgrowleyml@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19742: `INTERSECT` under a `UNION ALL` with an empty arm fails with "could not find pathkey item t"
In-Reply-To: <1087303.1791221946@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox