On 25.05.21 17:20, Tom Lane wrote:
> I don't really see how you can argue that the existing behavior is
> more spec-compliant than what I'm suggesting. What I read in the spec
> (SQL:2021 10.4 <routine invocation> SR 9) h) iii) 1)) is
>
> 1) If Pi is an output SQL parameter, then XAi shall be a <target
> specification>.
>
> (where <target specification> more or less reduces to "variable").
> Now, sure, that's what we've got in plpgsql, and I'm not proposing
> to change that. But in plain SQL, as of HEAD, you are supposed to
> write NULL, or a random literal, or indeed anything at all *except*
> a variable. How is that more standard-compliant than not writing
> anything?
I concede that the current implementation is not fully standards
compliant in this respect. Maybe we need to rethink how we can satisfy
this better. For example, in some other implementations, you write CALL
p(?), (where ? is the parameter placeholder), so it's sort of an output
parameter. However, changing it so that the entire way the parameters
are counted is different seems a much greater departure.
> More generally, there are enough deviations from spec in what we do
> to perform ambiguous-call resolution that it seems rather silly to
> hang your hat on this particular point.
I don't know what you mean by this. Some stuff is different in the
details, but you *can* write conforming code if you avoid the extremely
complicated cases. With your proposal, everything is always different,
and we might as well remove the CALL statement and name it something
else because users migrating from other systems won't be able to use it
properly.
> Now as against that, we are giving up a whole lot of consistency.
> As of HEAD:
>
> * The rules for what is a conflict of signatures are different
> for functions and procedures.
But that's the fault of the way it was done for functions. That doesn't
mean we have to repeat it for procedures. I mean, sure it would be
better if it were consistent. But SQL-standard syntax should behave in
SQL standard ways. Creating, altering, and dropping procedures is meant
to be portable between SQL implementations. If we change this in subtle
ways so that DROP PROCEDURE p(int, int) drops a different procedure in
different SQL implementations, that seems super-dangerous and annoying.