Re: Do CustomScan as not projection capable node

From: Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Do CustomScan as not projection capable node
Date: 2019-04-22 17:23:28
Message-ID: 7952e2b4-be6c-57fa-40c4-bb570c8e9449@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 22/04/2019 18:40, Robert Haas wrote:
> On Fri, Apr 19, 2019 at 12:45 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2019-04-22 17:24:24 Re: Thoughts on nbtree with logical/varwidth table identifiers, v12 on-disk representation
Previous Message Michał phoe Herda 2019-04-22 17:20:02 Re: Allow any[] as input arguments for sql/plpgsql functions to mimic format()