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: Julien Rouhaud <rjuju123@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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-19T20:03:50Z
Lists: pgsql-bugs, pgsql-hackers
On Wed, 20 Feb 2019 at 06:48, Julien Rouhaud <rjuju123@gmail.com> wrote: > > On Tue, Feb 19, 2019 at 5:46 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > > Julien Rouhaud <rjuju123@gmail.com> writes: > > > > > > 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. > > It does, I was just wondering whether that was a good enough solution. > > Thinking more about it, I'm not sure if there's a general policy for > enums, but should we have an AssertArg() in LookupFuncName[WithArgs] > to check that a correct value was passed? I think since the original argument was a bool then it's pretty unlikely that such an assert would ever catch anything, given 0 and 1 are both valid values for this enum type. -- 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