On Wed, May 16, 2018 at 3:29 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
I am not endorsing the patch and haven't looked at it, but I don't buy
the idea that having CALL prefer procedures and SELECT functions would
confuse people more than what we've got already. As we have it,
creating an uncallable object can make CALL fail, which is certainly a
POLA violation. You might be be able to convince me that it's better
than the alternatives, but it can't possibly be *good*.
> 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?
Good question.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
