Re: CALL versus procedures with output-only arguments

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: CALL versus procedures with output-only arguments
Дата
Msg-id 1250125.1621966825@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: CALL versus procedures with output-only arguments  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: CALL versus procedures with output-only arguments  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
I wrote:
> * The rules for how to identify a target routine in ALTER, DROP,
> etc are different for functions and procedures.  That's especially
> nasty in ALTER/DROP ROUTINE, where we don't have a syntax cue
> as to whether or not to ignore OUT parameters.

Just to enlarge on that point a bit:

regression=# create function foo(int, out int) language sql
regression-# as 'select $1';
CREATE FUNCTION
regression=# create procedure foo(int, out int) language sql
regression-# as 'select $1';
CREATE PROCEDURE

IMO this should have failed, but since it doesn't:

regression=# drop routine foo(int, out int);
DROP ROUTINE

Which object was dropped, and what is the argument for that one
being the right one?

Experinentation shows that in HEAD, what is dropped is the procedure,
and indeed the DROP will fail if you try to use it on the function.
That is a compatibility break, because in previous versions this
worked:

regression=# create function foo(int, out int) language sql
as 'select $1';
CREATE FUNCTION
regression=# drop routine foo(int, out int);
DROP ROUTINE

The fact that you now have to be aware of these details to use
ALTER/DROP ROUTINE seems like a pretty serious loss of user
friendliness, as well as compatibility.

            regards, tom lane



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: CALL versus procedures with output-only arguments
Следующее
От: Robert Haas
Дата:
Сообщение: Re: storing an explicit nonce