Re: BUG #17700: An assert failed in prepjointree.c - Mailing list pgsql-bugs

From Richard Guo
Subject Re: BUG #17700: An assert failed in prepjointree.c
Date
Msg-id CAMbWs49E2VtKdG=T0aPC0_DsO1x2yf1nmxxVaxEwQ58k6aCRyQ@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17700: An assert failed in prepjointree.c  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: BUG #17700: An assert failed in prepjointree.c
List pgsql-bugs

On Tue, Nov 29, 2022 at 8:12 AM Richard Guo <guofenglinux@gmail.com> wrote:
On Tue, Nov 29, 2022 at 12:22 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Actually ... it seems like we could just drop that Assert, as per
revised argument in the comment.  This'd explain the lack of field
complaints: there's no bug in a production build.
 
Ah yes, that's right.  We can be sure that above the semijoin there
would be no reference to its RHS.  And the PHV in semijoin's qual seems
unnecessary.

This reminds me of another question I had about unwrapping unnecessary
PHVs [1].  Sad that we don't have infrastructure for that.
 
BTW, for the test case

+explain (verbose, costs off)
+with ctetable as not materialized ( select 1 as f1 )
+select * from ctetable c1
+where f1 in ( select c3.f1 from ctetable c2 full join ctetable c3 on true );

Actually we just need to keep 'c3' in a join's nullable side to have the
PHV created.  So we don't have to use full join in the subquery.  A left
join would do.

Thanks
Richard

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: daterange() is ignoring 3rd boundaries argument
Next
From: Tom Lane
Date:
Subject: Re: BUG #17700: An assert failed in prepjointree.c