David Rowley <david.row...@2ndquadrant.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
