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: Julien Rouhaud <rjuju123@gmail.com>
Cc: David Rowley <david.rowley@2ndquadrant.com>,
Michael Paquier <michael@paquier.xyz>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Ash M <makmarath@hotmail.com>,
PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2019-02-19T16:45:59Z
Lists: pgsql-bugs, pgsql-hackers
Julien Rouhaud <rjuju123@gmail.com> writes: > On Sun, Feb 17, 2019 at 11:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Yeah, exactly. Not only do I not feel a need to change this behavior >> in the back branches, but the original patch is *also* an API change, >> in that it changes the behavior of what appears to be a well-defined >> boolean parameter. The fact that none of the call sites found in >> core today would care doesn't change that; you'd still be risking >> breaking extensions, and/or future back-patches. > Extensions calling those functions with old true/false values probably > won't get any warning or error during compile. Is is something we > should worry about or is it enough to keep the same behavior in this > case? Yeah, I thought about that. We can avoid such problems by assigning the enum values such that 0 and 1 correspond to the old behaviors. I didn't look to see if the proposed patch does it like that right now, but it should be an easy fix if not. regards, tom lane
Commits
-
Improve error reporting for DROP FUNCTION/PROCEDURE/AGGREGATE/ROUTINE.
- bfb456c1b965 12.0 landed