On 2016/12/08 21:08, Etsuro Fujita wrote:
> On 2016/12/07 20:23, Etsuro Fujita wrote:
>> My proposal here would be a bit different from what you proposed; right
>> before deparseSelectSql in deparseSelectStmtForRel, build the tlists for
>> relations present in the given jointree that will be deparsed as
>> subqueries, by (1) traversing the given jointree and (2) applying
>> build_tlist_to_deparse to each relation to be deparsed as a subquery and
>> saving the result in that relation's fpinfo. I think that would be
>> implemented easily, and the overhead would be small.
> I implemented that to address your concern:
> * deparseRangeTblRef uses the tlist created as above, to build the
> SELECT clause of the subquery. (You said "Then in deparseRangeTblRef()
> assert that there's a tlist in fpinfo", but the tlist may be empty, so I
> didn't add any assertion to that function.)
> * get_relation_column_alias_ids uses tlist_member with the tlist.
>
> I also addressed the comments #1, #2 and #3 in [1]. For #1, I added
> "LIMIT 10" to the query. Attached is the new version of the patch.
>
> Other changes:
> * As discussed before, renamed grouped_tlist in fpinfo to "tlist" and
> used it to store the tlist created as above.
> * Also, renamed SS_REL_ALIAS_PREFIX to SUBQUERY_REL_ALIAS_PREFIX
> (Likewise for SS_COL_ALIAS_PREFIX).
> * Relocated some functions.
> * Revised comments a little bit.
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). And I rebased another patch
for PHVs against that patch, which is also attached
(postgres-fdw-phv-pushdown-v14.patch).
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