On Tue, Feb 19, 2019 at 9:04 PM David Rowley
<david.rowley@2ndquadrant.com> wrote:
>
> 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.
Indeed. It looks all fine to me in v6, so I'm marking the patch as
ready for committer.
Thanks!
