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