Re: Postgres_fdw join pushdown - wrong results with whole-row reference
От | Ashutosh Bapat |
---|---|
Тема | Re: Postgres_fdw join pushdown - wrong results with whole-row reference |
Дата | |
Msg-id | CAFjFpRdafKrACEC0r5P3fbm6xRi45SUQNsC6F2Vz=U563W9Crw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Postgres_fdw join pushdown - wrong results with whole-row reference (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: Postgres_fdw join pushdown - wrong results with
whole-row reference
|
Список | pgsql-hackers |
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.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
В списке pgsql-hackers по дате отправления: