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
