Re: CALL stmt, ERROR: unrecognized node type: 113 bug

2018-02-09 15:15 GMT+01:00 David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>:

> On Fri, Feb 9, 2018 at 6:23 AM, Michael Paquier <michael(at)paquier(dot)xyz>
> wrote:
>
>> On Fri, Feb 09, 2018 at 12:02:57PM +0100, Pavel Stehule wrote:
>> > 2018-02-09 7:56 GMT+01:00 Michael Paquier <michael(at)paquier(dot)xyz>:
>> > > The second problem involves a cache lookup failure for a type when
>> > > trying to use pg_get_functiondef on a procedure. Luckily, it is
>> > > possible to make the difference between a procedure and a function by
>> > > checking if prorettype is InvalidOid or not. There is room for a new
>> > > patch which supports pg_get_proceduredef() to generate the definition
>> of
>> > > a procedure, with perhaps a dedicated psql shortcut, but that could
>> > > always be done later on.
>> >
>> > Blocking subqueries in CALL parameters is possible solution.
>>
>> ExecuteCallStmt has visibly been written so as it is able to handle the
>> input set of arguments with a minimal infrastructure in place. SubLink
>> nodes require more advanced handling as those need to go through the
>> planner. There is also additional processing in the rewriter. At the
>> end I tend to think that any user would just turn their back on calling
>> a function for such cases anyway, so it seems to me that the potential
>> benefits are not worth the code complexity.
>>
>
> ​CALL is not just a different syntax for function invocation - if you want
> the properties of CALL then falling back to SELECT function() is not a
> valid alternative.​
>

+1

>
> To me this feels like an interaction between two features that users are
> going to expect to just work. Current discussions lead me to think that is
> something we strive to provide unless a strong argument against is
> provided. I'm not sure added code complexity here is going to make the
> grade even if I cannot reasonably judge just how much complexity is
> involved.
>

when some procedure can do transaction control, or can returns possible set
or multirecord set (in future), then 100% agree, so it is different
creature then function. But if not, then it should be specified why it is
different from void function.

I don't understand, why we should to prohibit subqueries as procedure
params - with some limits. I can understand to requirement to not change
any data.

Regards

Pavel

>
> David J.
>
>