| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Thom Brown <thom(at)linux(dot)com>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API) |
| Date: | 2015-05-10 18:42:28 |
| Message-ID: | 16758.1431283348@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I've committed a cleanup patch along the lines discussed.
One thought is that we could test the nondefault-scan-tuple logic without
a lot of work by modifying the way postgres_fdw deals with columns it
decides don't need to be fetched. Right now it injects NULL columns so
that the remote query results still match the foreign table's rowtype,
but that's not especially desirable or efficient. What we could do
instead is generate an fdw_scan_tlist that just lists the columns we
intend to fetch.
I don't have time to pursue this idea right now, but I think it would be
a good change to squeeze into 9.5, just so that we could have some test
coverage on those parts of this patch.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2015-05-10 20:01:53 | Re: BUG #13148: Unexpected deferred EXCLUDE constraint violation on derived table |
| Previous Message | David G. Johnston | 2015-05-10 18:40:10 | Re: BUG #13148: Unexpected deferred EXCLUDE constraint violation on derived table |