Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name
David Rowley <david.rowley@2ndquadrant.com>
From: David Rowley <david.rowley@2ndquadrant.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Ash M <makmarath@hotmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2019-01-07T23:55:54Z
Lists: pgsql-bugs, pgsql-hackers
Attachments
- drop_func_if_not_exists_fix.patch (application/octet-stream) patch
On Tue, 8 Jan 2019 at 03:54, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > I'm not sure what's a good way to implement this, however. Maybe the > solution is to have LookupFuncName return InvalidOid when the function > name is ambiguous and let LookupFuncWithArgs report the error > appropriately. I think this behavior is weird: > > /* > * When looking for a function or routine, we pass noError through to > * LookupFuncName and let it make any error messages. Otherwise, we make > * our own errors for the aggregate and procedure cases. > */ > oid = LookupFuncName(func->objname, func->args_unspecified ? -1 : argcount, argoids, > (objtype == OBJECT_FUNCTION || objtype == OBJECT_ROUTINE) ? noError : true); Why can't we just remove the !noError check in the location where the error is raised? I had a look and I can't see any other callers that pass nargs as -1 and can pass noError as true. The only place I see is through get_object_address() in RemoveObjects(). There's another possible call in get_object_address_rv(), but there's only 1 call in the entire source for that function and it passes missing_ok as false. I ended up with the attached. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
-
Improve error reporting for DROP FUNCTION/PROCEDURE/AGGREGATE/ROUTINE.
- bfb456c1b965 12.0 landed