Re: pgsql: Improve error reporting for DROPFUNCTION/PROCEDURE/AGGREGATE/RO

Hi,

On 2019-03-21 15:52:23 +0000, Tom Lane wrote:
> Improve error reporting for DROP FUNCTION/PROCEDURE/AGGREGATE/ROUTINE.
> 
> These commands allow the argument type list to be omitted if there is
> just one object that matches by name.  However, if that syntax was
> used with DROP IF EXISTS and there was more than one match, you got
> a "function ... does not exist, skipping" notice message rather than a
> truthful complaint about the ambiguity.  This was basically due to
> poor factorization and a rats-nest of logic, so refactor the relevant
> lookup code to make it cleaner.
> 
> Note that this amounts to narrowing the scope of which sorts of
> error conditions IF EXISTS will bypass.  Per discussion, we only
> intend it to skip no-such-object cases, not multiple-possible-matches
> cases.
> 
> Per bug #15572 from Ash Marath.  Although this definitely seems like
> a bug, it's not clear that people would thank us for changing the
> behavior in minor releases, so no back-patch.
> 
> David Rowley, reviewed by Julien Rouhaud and Pavel Stehule
> 
> Discussion: https://postgr.es/m/15572-ed1b9ed09503de8a@postgresql.org

I now get:

/home/andres/src/postgresql/src/backend/parser/parse_func.c: In function ‘LookupFuncWithArgs’:
/home/andres/src/postgresql/src/backend/parser/parse_func.c:2285:5: warning: this statement may fall through
[-Wimplicit-fallthrough=]
     switch (objtype)
     ^~~~~~
/home/andres/src/postgresql/src/backend/parser/parse_func.c:2336:4: note: here
    case FUNCLOOKUP_AMBIGUOUS:
    ^~~~

which seems like a somewhat righteous complaint? I'd just add a break to
silence it (which can't be reached, because all paths ought to error
out).

Greetings,

Andres Freund