From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: CALL versus procedures with output-only arguments |
Date: | 2021-05-26 17:28:07 |
Message-ID: | 1548963.1622050087@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
(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'm not opposed to reverting the feature if we can't find a good
> solution in a hurry.
I'm not looking to revert the feature. I mainly want a saner catalog
representation, and less inconsistency in object naming (which is
tightly tied to the first thing).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Zhihong Yu | 2021-05-26 17:35:00 | Re: Skip partition tuple routing with constant partition key |
Previous Message | Tom Lane | 2021-05-26 16:45:38 | Re: Replacing pg_depend PIN entries with a fixed range check |