2018-02-09 15:15 GMT+01:00 David G. Johnston <david.g.johns...@gmail.com>:

> On Fri, Feb 9, 2018 at 6:23 AM, Michael Paquier <mich...@paquier.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 <mich...@paquier.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.​


> 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.



> David J.

Reply via email to