On Wed, May 22, 2019 at 4:47 PM Michael Paquier wrote:
>
> On Wed, May 22, 2019 at 04:32:38AM +0900, Fujii Masao wrote:
> > I found that tab-completion also needs to be updated for ANALYZE
> > boolean options. I added that change for tab-completion into
> > the patch and am thinking to apply the
On Wed, May 22, 2019 at 04:32:38AM +0900, Fujii Masao wrote:
> I found that tab-completion also needs to be updated for ANALYZE
> boolean options. I added that change for tab-completion into
> the patch and am thinking to apply the attached patch.
Looks fine to me at quick glance.
--
Michael
On Tue, May 21, 2019 at 11:47 AM Masahiko Sawada wrote:
>
> On Tue, May 21, 2019 at 2:10 AM Fujii Masao wrote:
> >
> > On Fri, May 17, 2019 at 10:21 AM Kyotaro HORIGUCHI
> > wrote:
> > >
> > > We now have several syntax elements seemingly the same but behave
> > > different way.
> > >
> > > At
Hi,
On 2019-05-21 16:00:25 +0900, Kyotaro HORIGUCHI wrote:
> At Tue, 21 May 2019 14:31:32 +0900, Michael Paquier
> wrote in <20190521053132.gg1...@paquier.xyz>
> > On Mon, May 20, 2019 at 09:55:59AM -0400, Robert Haas wrote:
> > > Well, it's confusing that we're not consistent about which
Michael Paquier writes:
> On Mon, May 20, 2019 at 09:55:59AM -0400, Robert Haas wrote:
>> Well, it's confusing that we're not consistent about which spellings
>> are accepted. The GUC system accepts true/false, on/off, and 0/1, so
>> it seems reasonable to me to standardize on that treatment
At Tue, 21 May 2019 14:31:32 +0900, Michael Paquier wrote
in <20190521053132.gg1...@paquier.xyz>
> On Mon, May 20, 2019 at 09:55:59AM -0400, Robert Haas wrote:
> > Well, it's confusing that we're not consistent about which spellings
> > are accepted. The GUC system accepts true/false, on/off,
On Mon, May 20, 2019 at 09:55:59AM -0400, Robert Haas wrote:
> Well, it's confusing that we're not consistent about which spellings
> are accepted. The GUC system accepts true/false, on/off, and 0/1, so
> it seems reasonable to me to standardize on that treatment across the
> board. That's not
On Tue, May 21, 2019 at 2:10 AM Fujii Masao wrote:
>
> On Fri, May 17, 2019 at 10:21 AM Kyotaro HORIGUCHI
> wrote:
> >
> > We now have several syntax elements seemingly the same but behave
> > different way.
> >
> > At Thu, 16 May 2019 15:29:36 -0400, Robert Haas
> > wrote in
> >
> > > On
> On Mon, May 20, 2019 at 9:20 PM Andres Freund wrote:
>
> Hi,
>
> On May 20, 2019 12:14:30 PM PDT, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> >> On Thu, May 16, 2019 at 8:56 PM Fujii Masao
> >wrote:
> >>
> >> Yes. Thanks for the comment!
> >> Attached is the updated version of the patch.
>
Hi,
On May 20, 2019 12:14:30 PM PDT, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>> On Thu, May 16, 2019 at 8:56 PM Fujii Masao
>wrote:
>>
>> Yes. Thanks for the comment!
>> Attached is the updated version of the patch.
>> It adds such common rule.
>
>If I understand correctly, it resulted in
> On Thu, May 16, 2019 at 8:56 PM Fujii Masao wrote:
>
> Yes. Thanks for the comment!
> Attached is the updated version of the patch.
> It adds such common rule.
If I understand correctly, it resulted in the commit fc7c281f8. For some reason
it breaks vacuum tests for me, is it expected?
On Fri, May 17, 2019 at 10:21 AM Kyotaro HORIGUCHI
wrote:
>
> We now have several syntax elements seemingly the same but behave
> different way.
>
> At Thu, 16 May 2019 15:29:36 -0400, Robert Haas wrote
> in
> > On Thu, May 16, 2019 at 2:56 PM Fujii Masao wrote:
> > > Yes. Thanks for the
On Thu, May 16, 2019 at 9:21 PM Kyotaro HORIGUCHI
wrote:
> I think we don't need to support 1/0 as boolean here (it's
> unnatural) and the documentation of VACUUM/ANALYZE should be
> fixed.
Well, it's confusing that we're not consistent about which spellings
are accepted. The GUC system accepts
On Thu, May 16, 2019 at 03:29:36PM -0400, Robert Haas wrote:
> I'm not sure how much value it really has to define
> opt_boolean_or_string_or_numeric. It saves 1 line of code in each of
> 3 places, but costs 6 lines of code to have it.
>
> Perhaps we could try to unify at a higher level. Like
Mmm. It has gone before complete.
At Fri, 17 May 2019 10:21:21 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190517.102121.72558057.horiguchi.kyot...@lab.ntt.co.jp>
> We now have several syntax elements seemingly the same but behave
> different way.
>
> At Thu, 16 May 2019
We now have several syntax elements seemingly the same but behave
different way.
At Thu, 16 May 2019 15:29:36 -0400, Robert Haas wrote
in
> On Thu, May 16, 2019 at 2:56 PM Fujii Masao wrote:
> > Yes. Thanks for the comment!
> > Attached is the updated version of the patch.
> > It adds such
On Thu, May 16, 2019 at 2:56 PM Fujii Masao wrote:
> Yes. Thanks for the comment!
> Attached is the updated version of the patch.
> It adds such common rule.
I'm not sure how much value it really has to define
opt_boolean_or_string_or_numeric. It saves 1 line of code in each of
3 places, but
On Wed, May 15, 2019 at 2:52 AM Andres Freund wrote:
>
> Hi,
>
> On 2019-05-15 02:45:21 +0900, Fujii Masao wrote:
> > VACUUM fails to parse 0 and 1 as boolean value
> >
> > The document for VACUUM explains
> >
> > boolean
> > Specifies whether the selected option should be turned on or
On Wed, May 15, 2019 at 2:52 AM Andres Freund wrote:
>
> Hi,
>
> On 2019-05-15 02:45:21 +0900, Fujii Masao wrote:
> > VACUUM fails to parse 0 and 1 as boolean value
> >
> > The document for VACUUM explains
> >
> > boolean
> > Specifies whether the selected option should be turned on or
On Wed, May 15, 2019 at 08:20:33AM +0900, Michael Paquier wrote:
> 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.
And I need more coffee at this time of the day...
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
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
Hi,
On 2019-05-15 02:45:21 +0900, Fujii Masao wrote:
> VACUUM fails to parse 0 and 1 as boolean value
>
> The document for VACUUM explains
>
> boolean
> Specifies whether the selected option should be turned on or off.
> You can write TRUE, ON, or 1 to enable the option, and FALSE,
Hi,
VACUUM fails to parse 0 and 1 as boolean value
The document for VACUUM explains
boolean
Specifies whether the selected option should be turned on or off.
You can write TRUE, ON, or 1 to enable the option, and FALSE, OFF,
or 0 to disable it.
But VACUUM fails to parse 0 and 1
24 matches
Mail list logo
