Re: CALL versus procedures with output-only arguments

On 26.05.21 19:28, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
>> AFAICT, your patch does not main the property that
>> CREATE PROCEDURE p1(OUT int, OUT int)
>> corresponds to
>> DROP PROCEDURE p1(int, int)
>> which would be bad.
>
> Why? If it actually works that way right now, I'd maintain
> strenously that it's broken. The latter should be referring
> to a procedure with two IN arguments. Even if the SQL spec
> allows fuzziness about that, we cannot afford to, because we
> have a more generous view of overloading than the spec does.

There is no fuzziness in the spec about this. See subclause <specific
routine designator>. It just talks about arguments, nothing about input
or output arguments. I don't find any ambiguity there. I don't see why
we want to reinvent this here.

If I have two procedures

p1(IN int, IN int, OUT int, OUT int)
p1(OUT int, OUT int)

then a DROP, or ALTER, or GRANT, etc. on p1(int, int) should operate on
the second one in a spec-compliant implementation, but you propose to
have it operate on the first one. That kind of discrepancy would be
really bad to have. It would be very difficult for migration tools to
check or handle this in a robust way.

> (As far as I could tell from looking at the spec yesterday,
> they think that you aren't allowed to have two procedures
> with the same name/schema and same number of arguments,
> regardless of the details of those arguments. Up with that
> I will not put.)

I don't see that.