On Tuesday, August 28, 2018, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> First of all, what do you want to do with the function return value
> when you use CALL?
> Place it in the result set.
> And would you expect a function that is invoked via CALL to have a
> non-atomic execution context, that is, allow transactions? If not,
> why not?
No, because functions cannot exercise transaction control.
Similar questions arise if we implement SQL standard dynamic result
> sets. What would you do if a function invoked by CALL runs across one
> of those?
Runtime error that record returning results are not supported for CALL
based execution.
> Moreover, if the intention is to switch the
> JDBC driver or similar drivers to use the CALL command always from
> PG11 on, then the meaning of {call f1(a, b)} will have changed and a
> lot of things will break in dangerous ways.
This seems like the main blocker.
> Always using CALL to invoke a function would also leave performance on
> the table. CALL has to do certain additional work in case a
> transaction commit happens in the middle of the procedure, such as
> expanding TOAST values. You don't necessarily want to do that if you
> don't have to.
This seems solvable since we know if the invoked object is a function or
procedure. And functions used as procedures are likely less sensitive to
performance concerns than ones performing calculations in tlists. Not
implementing this optimization in pg11 but supporting functions via call is
something I could live with.
> There is also the semi-open question of whether functions and
> procedures should be in separate namespaces.
I have no problem calling this a closed question answered per the initial
implementation choice. This matter is sufficient justification fevn if the
original choice was done out of convenience.
David J.
