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: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Ash M <makmarath@hotmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2019-01-15T23:38:55Z
Lists: pgsql-bugs, pgsql-hackers

Attachments

On Wed, 9 Jan 2019 at 13:36, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <david.rowley@2ndquadrant.com> writes:
> > Why can't we just remove the !noError check in the location where the
> > error is raised?
>
> I don't like that a bit --- the point of noError is to prevent throwing
> errors, and it doesn't seem like it should be LookupFuncName's business
> to decide it's smarter than its callers.  Maybe we need another flag
> argument?

Well, I guess you didn't have backpatching this in mind.  The reason I
thought it was okay to hijack that flag was that the ambiguous error
was only raised when the function parameters were not defined.  I
chased around and came to the conclusion this only happened during
DROP.  Maybe that's a big assumption as it certainly might not help
future callers passing nargs as -1.

I've attached another version with a newly added flag.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Commits

  1. Improve error reporting for DROP FUNCTION/PROCEDURE/AGGREGATE/ROUTINE.