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