On Sun, Feb 17, 2019 at 11:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <david.rowley@2ndquadrant.com> writes:
> > On Tue, 12 Feb 2019 at 16:09, Michael Paquier <michael@paquier.xyz> wrote:
> >> FWIW, it makes me a bit uneasy to change this function signature in
> >> back-branches if that's the intention as I suspect that it gets used
> >> in extensions.. For HEAD that's fine of course.
>
> > I wondered about this too and questioned Tom about it above. There
> > was no response.
>
> Sorry, I didn't realize you'd asked a question.
>
> > I just assumed Tom didn't think it was worth fiddling with in back-branches.
>
> 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?
@david: small typo, you removed a space in this chunk
- * LookupFuncName and let it make any error messages. Otherwise, we make
+ * LookupFuncNameand let it make any error messages. Otherwise, we make