Re: VACUUM fails to parse 0 and 1 as boolean value

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: VACUUM fails to parse 0 and 1 as boolean value
Date: 2019-05-20 02:47:08
Message-ID: CAHGQGwEMPtKzh6e+JVN8N1cZWdCz9TN7yk7_qURD5AC8BkjTrQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 17, 2019 at 10:35 AM Michael Paquier <michael(at)paquier(dot)xyz> 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 it.
> >
> > Perhaps we could try to unify at a higher level. Like can we merge
> > vac_analyze_option_list with explain_option_list?
>
> var_value has also similar semantics, and it uses makeAConst(). At
> this point of the game, I'd like to think that it would be just better
> to leave all the refactoring behind us on HEAD, to apply the first
> patch presented on this thread, and to work more on that for v13 once
> it opens for business if there is a patch to discuss about.

We can refactor the gram.y several ways and it's not good to
rush the partial refactoring code into v12 before beta.
I'm ok to apply the first patch and focus on the bugfix at this moment.

Regards,

--
Fujii Masao

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-05-20 02:50:18 Re: Why does ExecComputeStoredGenerated() form a heap tuple
Previous Message Masahiko Sawada 2019-05-20 02:43:19 Re: New vacuum option to do only freezing