Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)
От | Julien Rouhaud |
---|---|
Тема | Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000) |
Дата | |
Msg-id | CAOBaU_ZE6+9YBL8htVC=hvV7Wv=Dd3i_Ze+NzW+ESuWpSsjoOw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)
|
Список | pgsql-bugs |
On Tue, Mar 5, 2019 at 6:29 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Julien Rouhaud <rjuju123@gmail.com> writes: > > > It seems to be due to 11cf92f6e2e which bypass adjust_paths_for_srfs() > > in case of dummy rel. I'm not familiar with that this code, but > > attached patch seems to fix the issue without breaking regression > > tests. > > Hm, yeah, that function is definitely a few bricks shy of a load. > The amount of code it's bypassing for the dummy-rel case is pretty > scary. While it doesn't look like anything except the SRF case is > actively broken, there's a lot of room there for somebody to insert > new code and not notice that they need to fix the dummy-rel path > as well. Having to duplicate the adjust_paths_for_srfs call doesn't > bode well for the future. > > I'm inclined to fix it by not having the early-return path, but rather > > if (is_dummy_rel) > { > // minimum possible amount of code here > } > else > { > // minimum possible amount of code here, too > } > > // maximum possible amount of code here That makes sense, I was also dubious of the previous fix. Attached v3 reorganizes the code this way. The adjust_paths_for_srfs call is now done after everything else. AFAICT it shouldn't matter, and regression tests still seem happy with it.
Вложения
В списке pgsql-bugs по дате отправления: