On 2017/01/03 17:28, Ashutosh Bapat wrote: I wrote:
I updated the patch a bit further: simplified the function name (s/build_subquery_rel_tlists/build_subquery_tlists/), and revised comments a little bit. Attached is an updated version (postgres-fdw-subquery-support-v14.patch).
Few comments
Thanks for the comments!
In build_subquery_tlists(), why don't we handle base relations? + if (foreignrel->reloptkind != RELOPT_JOINREL) + return;
The reason for that is we don't need to handle the baserel cases; the tlist for a base relation, if needed, would be created while recursing into a join relation that joins the base relation to other base/join relation.
Also, in this function, if fpinfo->tlist is already set, why do we want to build it again?
When this function gets called, fpinfo->tlist isn't set for any base or join relation that needs to build the tlist, so we always need to build it for each such relation.
In build_tlist_to_deparse(), if fpinfo->tlist for the given relation is set, we should just return it rather than constructing it again.
In that function we wouldn't have such cases for base or join relations needing the tlist.
Best regards, Etsuro Fujita -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
