From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: CALL versus procedures with output-only arguments |
Date: | 2021-05-25 18:20:25 |
Message-ID: | 1250125.1621966825@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2021-05-25 18:25:21 | Re: storing an explicit nonce |
Previous Message | Peter Eisentraut | 2021-05-25 18:04:01 | Re: CALL versus procedures with output-only arguments |