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

David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> [ drop_func_if_not_exists_fix_v9.patch ]

Pushed with mostly-cosmetic adjustments.

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?

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.

I'm inclined to leave point 2 alone, because we haven't had complaints
about it, and because I'm not sure we could make it behave in a clean
way given the historical ambiguity about what OBJECT_FUNCTION should
match. But perhaps it's worth discussing.

regards, tom lane