Re: CALL versus procedures with output-only arguments

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: CALL versus procedures with output-only arguments
Дата
Msg-id 1548963.1622050087@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: CALL versus procedures with output-only arguments  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: CALL versus procedures with output-only arguments  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: CALL versus procedures with output-only arguments  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список pgsql-hackers
Peter Eisentraut <peter.eisentraut@enterprisedb.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Replacing pg_depend PIN entries with a fixed range check
Следующее
От: Zhihong Yu
Дата:
Сообщение: Re: Skip partition tuple routing with constant partition key