Re: VACUUM fails to parse 0 and 1 as boolean value - Mailing list pgsql-hackers

From Andres Freund
Subject Re: VACUUM fails to parse 0 and 1 as boolean value
Date
Msg-id 20190514232618.t4vxqgpnoutghiz7@alap3.anarazel.de
Whole thread Raw
In response to Re: VACUUM fails to parse 0 and 1 as boolean value  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Hi,

On 2019-05-15 08:20:33 +0900, Michael Paquier wrote:
> On Tue, May 14, 2019 at 10:52:23AM -0700, Andres Freund wrote:
> > Might be worth having a common rule for such options, so we don't
> > duplicate the knowledge between different places.
> > 
> > CCing Robert and Sawada-san, who committed / authored that code.
> 
> Hmn.  I think that Robert's commit is right to rely on defGetBoolean()
> for option parsing.  That's what we use for anything from CREATE
> EXTENSION to CREATE SUBSCRIPTION, etc.

That seems like a separate angle? What does that have to do with
accepting 0/1 in the grammar? I mean, EXPLAIN also uses defGetBoolean(),
while accepting NumericOnly for the option values?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: VACUUM fails to parse 0 and 1 as boolean value
Next
From: Michael Paquier
Date:
Subject: Re: VACUUM fails to parse 0 and 1 as boolean value