On 22/04/2019 18:40, Robert Haas wrote:
> On Fri, Apr 19, 2019 at 12:45 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I don't buy this for a minute. Where do you think projection is
>> going to happen? There isn't any existing node type that *couldn't*
>> support projection if we insisted that that be done across-the-board.
>> I think it's mostly just a legacy thing that some don't.
>
> I think there may actually be some good reasons for that. If
> something like an Append or Material node projects, it seems to me
> that this means that we built the wrong tlist for its input(s).
>
> That justification doesn't apply to custom scans, though.
The main reason for my question was incomplete information about the
parameter custom_scan_tlist / fdw_scan_tlist.
In the process of testing my custom node, I encountered an error in
setrefs.c caused by optimization of the projection operation. In order
to reliably understand how to properly use custom_scan_tlist, I had to
study in detail the mechanics of the FDW plan generator and now the
problem is solved.
We have only three references to this parameter in the hackers mailing
list, a brief reference on postgresql.org and limited comments into two
patches: 1a8a4e5 and e7cb7ee.
It is possible that custom_scan_tlist is designed too nontrivially, and
it is possible that it needs some comments describing in more detail how
to use it.
--
Andrey Lepikhov
Postgres Professional
https://postgrespro.com
The Russian Postgres Company
