Re: Problems with "pg.dropped" column after upgrade 9.5 to 9.6
От | Michael Paquier |
---|---|
Тема | Re: Problems with "pg.dropped" column after upgrade 9.5 to 9.6 |
Дата | |
Msg-id | CAB7nPqRsLqTWM4VgcurYxOHsUdHX-GJoyW+XWXu=Ztqccv4E_g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Problems with "pg.dropped" column after upgrade 9.5 to 9.6 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Thu, Nov 3, 2016 at 2:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > After further poking around, I concluded that it'd be a good idea to make > a similar change in set_dummy_tlist_references(), to prevent a failure > if the top plan node below ModifyTable chances to be a Sort or other > non-projecting plan node. I'm not sure such a case can arise today, but > I'm not sure it can't either. [ ... Back on this thread ... ] Thanks for the input! It would have taken waaay longer to me to figure out a clean patch. I am not very familiar with this code :) > I'm not sure if it's worth memorializing the specific test case discussed > in this thread as a regression test. It depends enough on the behavior > of SQL function planning that I wouldn't have much confidence in it > continuing to test what we meant it to test going forward. Definitely fine to not include it for me, the regression tests modified by your patch and the git history are enough to understand the story of the fix. -- Michael
В списке pgsql-bugs по дате отправления: