Robert Haas <robertmh...@gmail.com> writes: > On Fri, Mar 23, 2018 at 10:42 AM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> On Fri, Mar 23, 2018 at 7:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> ISTM this patch effectively proposes to make procedures have their own >>> namespace yet still live in pg_proc. That is the worst of all possible >>> worlds IMO.
> ... That does not mean -- to me anyway > -- that we've got to make CALL latch onto a function when a procedure > is available. My opinion remains unchanged. If you're unhappy about the system confusing procedure foo(int) and function foo(real), maybe the answer is to not overload the name "foo" with such enthusiasm. But putting kluges into (some of) the lookup rules is just going to lead to its own problems and surprising results. In particular, I dislike the idea that this patch would make routine names appear unique in some cases when they do not in others. Overloading is complicated/confusing enough without that. BTW, we seem to have some confusion here already: regression=# create function foo(int) returns int as 'select $1' language sql; CREATE FUNCTION regression=# create procedure foo(text) as 'select $1' language sql; CREATE PROCEDURE regression=# drop function foo; ERROR: function name "foo" is not unique HINT: Specify the argument list to select the function unambiguously. regression=# drop routine foo; ERROR: function name "foo" is not unique HINT: Specify the argument list to select the function unambiguously. regression=# drop procedure foo; ERROR: could not find a procedure named "foo" The first two errors are what I'd expect, but why is the third different? regards, tom lane