Re: Odd system-column handling in postgres_fdw join pushdown patch

<div dir="ltr"><br /><div class="gmail_extra"><br /><div class="gmail_quote">On Fri, Apr 15, 2016 at 9:39 PM, Robert
Haas<span dir="ltr"><<a href="mailto:robertmhaas@gmail.com" target="_blank">robertmhaas@gmail.com</a>></span>
wrote:<br/><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">OnThu, Apr 14, 2016 at 7:49 AM, Ashutosh Bapat<br /> <<a
href="mailto:ashutosh.bapat@enterprisedb.com">ashutosh.bapat@enterprisedb.com</a>>wrote:<br /> > BTW, I noticed
thatwe are deparsing whole-row reference as ROW(list of<br /> > columns from local definition of foreign table),
whichhas the same problem<br /> > with outer joins. It won't be NULL when the rest of the row from that<br /> >
relationis NULL in an outer join. It too needs to be encapsulated in CASE<br /> > WHEN .. END expression. PFA patch
withthat fix included and also some<br /> > testcases for system columns as well as whole-row references.<br /><br
/></span>Goodcatch.  But your test cases are no good because then we have OIDs<br /> hardcoded in the expected output. 
Thatmeans 'make installcheck' will<br /> fail, or if for any other reason the OID varies it will also fail.<br />
Committedyour version with those test cases.<br /><div class="HOEnZb"><div class="h5"><br
/></div></div></blockquote></div><br/></div><div class="gmail_extra">The testcases had tableoid::regclass which outputs
theforeign table's local name, which won't change across runs. Isn't that so?<br clear="all" /><br /></div><div
class="gmail_extra">--<br /><div class="gmail_signature"><div dir="ltr">Best Wishes,<br />Ashutosh Bapat<br
/>EnterpriseDBCorporation<br />The Postgres Database Company<br /></div></div></div></div>