Re: CALL versus procedures with output-only arguments

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> So while I understand the argument of
> - Function signatures should work consistently with procedure signatures.
> I find the arguments of
> - Procedure signatures should match the SQL standard, and
> - Signature for invoking should match signature for calling.
> a more appealing combination.
> Does that summarize the issue correctly?

Well, mumble ... I think you've left out a couple of significant
problems. The two things that I'm seriously unhappy about are:

1. ALTER/DROP ROUTINE is basically broken. It does not work the
same as it did before for functions; as I showed upthread, there
are cases that worked in prior versions and fail in HEAD. Moreover
it's impossible to make it work in any remotely consistent fashion,
because there are two incompatible standards for it to follow.

2. I really do not like considering OUT arguments as part of a
procedure's unique signature, because that means that you can
have both of
create procedure p1(IN x int, IN y int, OUT z int) ...
create procedure p1(IN x int, IN y int, OUT z text) ...
The key problem with this is that it breaks the advice that
"you can just write NULL for the output argument(s)". Sometimes
you'll have to write something else to select the procedure you
wanted. That's not per the documentation, and it's also going
to be a thorn in the side of client software that would like
to use "?" or some other type-free syntax for OUT parameters.

Given the fact that the spec won't allow you to have two procedures
with the same number of parameters (never mind their types), there's
no argument that this scenario needs to be allowed per spec. So
I think we would be very well advised to prevent it. This is why
I'm so hot about reverting the definition of proargtypes.

It's possible that we could revert proargtypes and still accommodate
the spec's definition for ALTER/DROP ROUTINE/PROCEDURE. I'm imagining
some rules along the line of:

1. If arg list contains any parameter modes, then it must be PG
syntax, so interpret it according to our traditional rules.

2. Otherwise, try to match the given arg types against *both*
proargtypes and proallargtypes. If we get multiple matches,
complain that the command is ambiguous. (In the case of DROP
PROCEDURE, it's probably OK to consider only proallargtypes.)

This is just handwaving at this point, so it might need some
refinement, but perhaps it could lead to an acceptable compromise.

regards, tom lane