Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)
От | Tom Lane |
---|---|
Тема | Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000) |
Дата | |
Msg-id | 21482.1551806937@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000) (Julien Rouhaud <rjuju123@gmail.com>) |
Ответы |
Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)
|
Список | pgsql-bugs |
Julien Rouhaud <rjuju123@gmail.com> writes: > On Tue, Mar 5, 2019 at 4:39 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Hmm, that's definitely a bug. It looks like we're forgetting to make >> a ProjectSet plan node for the unnest() if we realize that the query >> is a no-op; but I'm not sure why 10.x doesn't have the same issue. >> Digging ... > 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 regards, tom lane
В списке pgsql-bugs по дате отправления: