Re: CALL stmt, ERROR: unrecognized node type: 113 bug - Mailing list pgsql-hackers

From Tom Lane
Subject Re: CALL stmt, ERROR: unrecognized node type: 113 bug
Date
Msg-id 1431.1518187361@sss.pgh.pa.us
Whole thread Raw
In response to Re: CALL stmt, ERROR: unrecognized node type: 113 bug  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: CALL stmt, ERROR: unrecognized node type: 113 bug  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: CALL stmt, ERROR: unrecognized node type: 113 bug  (Andres Freund <andres@anarazel.de>)
Re: CALL stmt, ERROR: unrecognized node type: 113 bug  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Fri, Feb 9, 2018 at 6:23 AM, Michael Paquier <michael@paquier.xyz> wrote:
>> On Fri, Feb 09, 2018 at 12:02:57PM +0100, Pavel Stehule wrote:
>>> Blocking subqueries in CALL parameters is possible solution.

> To me this feels like an interaction between two features that users are
> going to expect to just work.

Meh.  It doesn't look significantly different to me than the restriction
that you can't have sub-selects in CHECK expressions, index expressions,
etc.  Obviously we need a clean failure like you get for those cases.
But otherwise it's an OK restriction that stems from exactly the same
cause: we do not want to invoke the full planner in this context (and
even if we did, we don't want to use the full executor to execute the
result).

            regards, tom lane


pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Is there a cache consistent interface to tables ?
Next
From: "David G. Johnston"
Date:
Subject: Re: CALL stmt, ERROR: unrecognized node type: 113 bug