Re: Odd procedure resolution

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Mar 23, 2018 at 10:42 AM, Ashutosh Bapat
> <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
>> On Fri, Mar 23, 2018 at 7:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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