Re: BUG #18764: server closed the connection unexpectedly

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Tue, 7 Jan 2025 at 02:14, Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
>> I've reached the same conclusion. I'm thinking about whether we
>> should refrain from pushing pathkeys into the subplan when type
>> conversion occurs at the set-operation level. Maybe we can do this
>> check in generate_setop_child_grouplist, like below.

> So I guess this must mean that we cannot assume that it's ever safe to
> assume that a type that is implicitly castable to the top setop's type
> sort order matches, so we must ensure we don't generate any
> setop_pathkeys for the subquery in this case.

The mere fact that there's an implicit cast sure doesn't make it safe.
We have implicit casts that cross sort-order behaviors (such as
integer to oid), and those would be just as big a hazard as this
example where the datatypes aren't physically compatible.

We could imagine detecting whether the subquery's datatype belongs
to the same btree opfamily as the outer query is using, and if so
adapting the pathkeys to that type. But I'm dubious that it's
worth the trouble: if this were a common case we'd have discovered
this bug sooner. So I'm for just not pushing down the pathkeys if
there's a type mismatch.

Didn't study the code, so have no opinion right now on the details
of how to check that.

regards, tom lane