On 3/19/18 03:25, Rushabh Lathia wrote:
> For the FUNCTION when we have single OUT/INOUT parameter
> the return type for that function will be set to the type of OUT parameter.
> But in case of PROCEDURE, it's always RECORDOID, why this inconsistency?
For procedures, this is just an implementation detail. The CALL command
returns a row in any case, so if we set the return type to a scalar
type, we'd have to add special code to reassemble a row anyway. For
functions, the inconsistency is (arguably) worth it, because it affects
how functions can be written and called, but for procedures, there would
be no point.
> Above test throws an error saying calling procedures with output
> arguments are not supported in SQL functions. Whereas similar test
> do work with SQL functions:
This was discussed earlier in the thread.
The behavior of output parameters in functions was, AFAICT, invented by
us. But for procedures, the SQL standard specifies it, so there might
be some differences.
> ERROR: calling procedures with output arguments is not supported in SQL
> functions
> CONTEXT: SQL function "ptest4b"
>
> Here error message says that calling procedures with output arguments is not
> supported in SQL functions. Whereas here it's getting called from the SQL
> procedure. So error message needs to be changed.
Well, I don't think we are going to change every single error message
from "function" to a separate function and procedure variant.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services