Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name

On Fri, 22 Mar 2019 at 05:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Pushed with mostly-cosmetic adjustments.

Thanks for pushing this.

> I noticed a couple of loose ends that are somewhat outside the scope
> of the bug report, but maybe are worth considering now:
>
> 1. There's some inconsistency in the wording of the error messages in
> these routines, eg
>
>              errmsg("%s is not a function",
> vs
>              errmsg("%s is not a procedure",
> vs
>              errmsg("function %s is not an aggregate",
>
> Also there's
>              errmsg("function name \"%s\" is not unique",
> where elsewhere in parse_func.c, we find
>              errmsg("function %s is not unique",
>
> You didn't touch this and I didn't either, but maybe we should try to
> make these consistent?

I think aligning those is a good idea.   I had just been wondering to
myself last night about how much binary space is taken up by needless
additional string constants that could be normalised a bit.
Translators might be happy if we did that.

> 2. Consider
>
> regression=# CREATE FUNCTION ambig(int) returns int as $$ select $1; $$ language sql;
> CREATE FUNCTION
> regression=# CREATE PROCEDURE ambig() as $$ begin end; $$ language plpgsql;
> CREATE PROCEDURE
> regression=# DROP PROCEDURE ambig;
> ERROR:  procedure name "ambig" is not unique
> HINT:  Specify the argument list to select the procedure unambiguously.
>
> Arguably, because I said "drop procedure", there's no ambiguity here;
> but we don't account for objtype while doing the lookup.

Yeah. I went with reporting the objtype that was specified in a
command.  I stayed well clear of allowing overlapping names between
procedures and functions.  It would be hard to put that back if we
ever discovered a reason we shouldn't have done it.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services