Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Michael Paquier <michael@paquier.xyz>,
Julien Rouhaud <rjuju123@gmail.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Ash M <makmarath@hotmail.com>,
PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2019-02-20T20:36:39Z
Lists: pgsql-bugs, pgsql-hackers
David Rowley <david.rowley@2ndquadrant.com> writes: > On Wed, 20 Feb 2019 at 18:56, Michael Paquier <michael@paquier.xyz> wrote: >> I think that the right call is to add the object type into the >> arguments of LookupFuncName(). I'm not clear how that helps exactly? > But there are plenty of callers that use LookupFuncName() directly. Do > you happen to know it's okay for all those to error out with the > additional error conditions that such a change would move into that > function? I certainly don't know that. The real problem here is that you've unilaterally decided that all callers of get_object_address() need a particular behavior --- and not only that, but a behavior that seems fairly surprising and unprincipled, given that get_object_address's option is documented as "missing_ok" (something the patch doesn't even bother to change). It's not very apparent to me why function-related lookups should start behaving differently from other lookups in that function, and it's sure not apparent that all callers of get_object_address() are on board with it. Should we be propagating that 3-way flag further up, to get_object_address() callers? I dunno. regards, tom lane
Commits
-
Improve error reporting for DROP FUNCTION/PROCEDURE/AGGREGATE/ROUTINE.
- bfb456c1b965 12.0 landed