Re: BUG #18170: Unexpected error: no relation entry for relid 3
От | Andrei Lepikhov |
---|---|
Тема | Re: BUG #18170: Unexpected error: no relation entry for relid 3 |
Дата | |
Msg-id | fc183714-a61c-4de7-97e0-b1c376923aef@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: BUG #18170: Unexpected error: no relation entry for relid 3 (Richard Guo <guofenglinux@gmail.com>) |
Ответы |
Re: BUG #18170: Unexpected error: no relation entry for relid 3
|
Список | pgsql-bugs |
On 30/10/2023 09:24, Richard Guo wrote: > > On Sun, Oct 29, 2023 at 11:56 PM Tom Lane <tgl@sss.pgh.pa.us > <mailto:tgl@sss.pgh.pa.us>> wrote: > > Alexander Korotkov <aekorotkov@gmail.com > <mailto:aekorotkov@gmail.com>> writes: > > I made some beautification of the patch by Andrei. I also > removed the > > part which changes the target list for estimate_num_groups(). Any > > objections to pushing this? > > It seems moderately likely that this will break as much as it fixes. > > I've not studied the original patch enough to understand why you need > to be playing strange games with tree mutation rules, but I suspect > that this is band-aiding over some rather fundamentally bad code. > > > I also have some concerns about this patch. It requires that > root->parse remains unchanged during the whole subquery_planner() in > order to work, which is an implicit constraint we did not have before. It is not about unchanged; it is about referencing the same query at the parent and child query blocks. Am I missing something? -- regards, Andrei Lepikhov Postgres Professional
В списке pgsql-bugs по дате отправления: