From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <david.rowley@2ndquadrant.com>
cc: Pavel Stehule <pavel.stehule@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: BUG #15572: Misleading message reported by "Drop function
 operation" on DB with functions having same name
In-reply-to: 
 <CAKJS1f9bfqQGESNC9QMLPs72pvTNkN595a5gAs4M1=Pj_Wb5YQ@mail.gmail.com>
References: <15572-ed1b9ed09503de8a@postgresql.org>
 <CAKJS1f8J5jKd9J60qK15H-sU93Fmz2X1U2QfY-a5mD6XgaqKVA@mail.gmail.com>
 <155300941700.16480.7948036003189357692.pgcf@coridan.postgresql.org>
 <CAKJS1f9bfqQGESNC9QMLPs72pvTNkN595a5gAs4M1=Pj_Wb5YQ@mail.gmail.com>
Comments: In-reply-to David Rowley <david.rowley@2ndquadrant.com>
	message dated "Thu, 21 Mar 2019 00:43:26 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <21615.1553184274.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 21 Mar 2019 12:04:34 -0400
Message-ID: <21616.1553184274@sss.pgh.pa.us>
Precedence: bulk

David Rowley <david.rowley@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=3D# CREATE FUNCTION ambig(int) returns int as $$ select $1; $$ =
language sql;
CREATE FUNCTION
regression=3D# CREATE PROCEDURE ambig() as $$ begin end; $$ language plpgs=
ql;
CREATE PROCEDURE
regression=3D# 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