On Tuesday, August 28, 2018, Peter Eisentraut <
peter.eisentraut@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.