Andrey Lepikhov writes:
> 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.
I totally buy the argument that the custom scan stuff is
underdocumented :-(.
FWIW, if we did have a use-cas
On 22/04/2019 18:40, Robert Haas wrote:
On Fri, Apr 19, 2019 at 12:45 AM Tom Lane 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.
On Fri, Apr 19, 2019 at 12:45 AM Tom Lane 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 thi
Andrey Lepikhov writes:
> Can we include the CustomScan node in the list of nodes that do not
> support projection?
That seems like a pretty bad idea. Maybe it's a good thing for whatever
unspecified extension you have in mind right now, but it's likely to be
a net negative for many more. As a
Can we include the CustomScan node in the list of nodes that do not
support projection?
Reason is that custom node can contain quite arbitrary logic that does
not guarantee projection support.
Secondly. If planner does not need a separate Result node, it just
assign tlist to subplan (i.e. change
