Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name

I second David J. Suggestion.

To add to the possible list of solutions I also propose another solution and for better consistency between both the operation

Fix the error message reported by the "drop function without IF Exists" and make it similar to the "Drop.. If Exists".

If no parameters are passed by user then let the "DROP FUNCTION" routine only check for a function of that name which has no parameters => "func1()"

Ash

A Marath.

________________________________
From: David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
Sent: Friday, January 4, 2019 1:10:05 AM
To: David Rowley
Cc: makmarath(at)hotmail(dot)com; pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name

On Thursday, January 3, 2019, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com<mailto:david(dot)rowley(at)2ndquadrant(dot)com>> wrote:
If we changed the behaviour of this then
someone might equally come along later and complain that they
specified "IF EXISTS" and got an error.

I’m inclined to argue that the docs say you can only use the omitted-args name if it is unique within the schema. Since the second case is using that form in violation of that requirement reporting an error would match the documentation.

IF EXISTS only applies when no functions exist; an error for ambiguity doesn’t violate its promise; and likely even if we didn’t make it an error something else will fail later on.

It is wrong for the drop function if exists command to translate/print the omitted-args form of the name into a function with zero arguments; it should not be looking explicitly for a zero-arg function as it is not the same thing (as emphasized in the docs).

So, I vote for changing this in 12 but leaving prior versions as-is for compatability as the harm doesn’t seem to be enough to risk breakage. Might be worth a doc patch showing the second case for the back branches (Head seems like it would be good as we are fixing the code to match the documentation, IMO).

David J.