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