Re: Problems with "pg.dropped" column after upgrade 9.5 to 9.6 - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: Problems with "pg.dropped" column after upgrade 9.5 to 9.6
Date
Msg-id CAB7nPqRsLqTWM4VgcurYxOHsUdHX-GJoyW+XWXu=Ztqccv4E_g@mail.gmail.com
Whole thread Raw
In response to Re: Problems with "pg.dropped" column after upgrade 9.5 to 9.6  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: BUG #14411: Issue with using OFFSET
Next
From: Michael Paquier
Date:
Subject: Re: BUG #14410: Restoring data not successful