On 3/8/18 02:25, Pavel Stehule wrote: > It looks like some error in this concept. The rules for enabling > overwriting procedures should modified, so this collision should not be > done. > > When I using procedure from PL/pgSQL, then it is clear, so I place on > *OUT position variables. But when I call procedure from top, then I'll > pass fake parameters to get some result.
What we'll probably want to do here is to make the OUT parameters part of the identity signature of procedures, unlike in functions. This should be a straightforward change, but it will require some legwork in many parts of the code.
yes
> if (argmodes && (argmodes[i] == PROARGMODE_INOUT || > argmodes[i] == PROARGMODE_OUT)) > + { > + Param *param; > > Because PROARGMODE_OUT are disallowed, then this check is little bit > messy. Please, add some comment.
Fixed.
I discovered another issue, in LANGUAGE SQL procedures. Currently, if you make a CALL with an INOUT parameter in an SQL procedure, the output is thrown away (unless it's the last command). I would like to keep open the option of assigning the results by name, like we do in PL/pgSQL. So in this patch I have made a change to prohibit calling procedures with INOUT parameters in LANGUAGE SQL routines (see check_sql_fn_statements()). What do you think?
The disabling it, it is probably the best what is possible now. The variables in SQL are more named parameters than variables. Is not necessary to complicate it.
Regards
Pavel
-- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
