Re: BUG #18429: Inconsistent results on similar queries with join lateral
От | Tom Lane |
---|---|
Тема | Re: BUG #18429: Inconsistent results on similar queries with join lateral |
Дата | |
Msg-id | 742265.1713190833@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18429: Inconsistent results on similar queries with join lateral (Richard Guo <guofenglinux@gmail.com>) |
Ответы |
Re: BUG #18429: Inconsistent results on similar queries with join lateral
|
Список | pgsql-bugs |
Richard Guo <guofenglinux@gmail.com> writes: > I agree that the new test case for v15 does not seem to be worth > including in v16+. It seems to me that it would be better if we can > have another new test case to verify that we've included child rel's > em_relids even for appendrel child relations with pseudoconstant > translated variables, i.e. to verify that the change in equivclass.c > takes effect. Maybe with a query like below: > explain (costs off) > select * from tenk1 t1 > left join lateral > (select t1.unique1 as t1u, 0 as c > union all > select t1.unique1 as t1u, 1 as c) s on true > where t1.unique1 = s.c; > Without the change in equivclass.c, this query would trigger the new > added assert in get_baserel_parampathinfo for v16, and give a wrong plan > for v15. What do you think? I didn't add such a test because there are already several cases (in foreign_data.sql, IIRC) that trigger the assert, which is how come I found the problem in the first place. Admittedly, those depend on potentially-changeable details of an information_schema view, so maybe it'd be better to have a bespoke test. regards, tom lane
В списке pgsql-bugs по дате отправления: