Re: Postgres_fdw join pushdown - wrong results with whole-row reference - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Postgres_fdw join pushdown - wrong results with whole-row reference
Date
Msg-id 666f80cc-2ed2-a8e2-9034-8bf0491aff45@lab.ntt.co.jp
Whole thread Raw
In response to Re: Postgres_fdw join pushdown - wrong results with whole-row reference  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
List pgsql-hackers
On 2016/06/22 18:14, Ashutosh Bapat wrote:
> I wonder whether such a whole-row-var would arise from the nullable side
>> of a join? I guess not.  Not that I'm saying we shouldn't account for that
>> case at all since any and every whole-row-var in the targetlist currently
>> gets that treatment, even those that are known non-nullable. Couldn't we
>> have prevented the latter somehow?  IOW, only generate the CASE WHEN when
>> a Var being deparsed is known nullable as the comment there says:
>>
>> deparse.c:
>>
>> 1639 /*
>> 1640  * In case the whole-row reference is under an outer join then it has
>> 1641  * to go NULL whenver the rest of the row goes NULL. Deparsing a join
>> 1642  * query would always involve multiple relations, thus qualify_col
>> 1643  * would be true.
>> 1644  */
>> 1645 if (qualify_col)
>> 1646 {
>> 1647     appendStringInfoString(buf, "CASE WHEN");
>> 1648     ADD_REL_QUALIFIER(buf, varno);
>> 1649     appendStringInfo(buf, "* IS NOT NULL THEN ");
>> 1650 }
>>
>> But I guess just fixing the expression as your patch does may be just fine.
>>
> I thought about that, but it means that we have compute the nullable relids
> (which isn't a big deal I guess). That's something more than necessary for
> fixing the bug, which is the focus in beta stage right now.

Agreed.

Thanks,
Amit





pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Postgres_fdw join pushdown - wrong results with whole-row reference
Next
From: Etsuro Fujita
Date:
Subject: Re: Postgres_fdw join pushdown - wrong results with whole-row reference