Re: BUG #17700: An assert failed in prepjointree.c

Поиск
Список
Период
Сортировка
От Richard Guo
Тема Re: BUG #17700: An assert failed in prepjointree.c
Дата
Msg-id CAMbWs49E2VtKdG=T0aPC0_DsO1x2yf1nmxxVaxEwQ58k6aCRyQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #17700: An assert failed in prepjointree.c  (Richard Guo <guofenglinux@gmail.com>)
Ответы Re: BUG #17700: An assert failed in prepjointree.c
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: daterange() is ignoring 3rd boundaries argument
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17700: An assert failed in prepjointree.c