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 a
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
sig
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 T
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 spelli
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 acro
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, an
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 ne
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 Thu
> 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 th
> 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?
AN
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 comme
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 Fri, May 17, 2019 at 10:35 AM Michael Paquier wrote:
>
> 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
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 ca
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 15:29:3
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 com
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 cos
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 wh
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 wh
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... B
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 t
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
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
25 matches
Mail list logo
