Re: [bug] Wrong bool value parameter

From: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
To: wenjing <wjzeng2012(at)gmail(dot)com>
Cc: Euler Taveira <euler(dot)taveira(at)2ndquadrant(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, Prabhat Sahu <prabhat(dot)sahu(at)enterprisedb(dot)com>
Subject: Re: [bug] Wrong bool value parameter
Date: 2020-04-08 12:25:59
Message-ID: CA+fd4k6rYwr33+Hf4aWmAdMDUT4iWjDmQV9aM6-o5AB5CScmsQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Wed, 8 Apr 2020 at 16:00, wenjing <wjzeng2012(at)gmail(dot)com> wrote:
>
>
>
> 2020年4月7日 下午10:35,Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com> 写道:
>
> On Tue, 7 Apr 2020 at 20:58, Euler Taveira
> <euler(dot)taveira(at)2ndquadrant(dot)com> wrote:
>
>
> On Tue, 7 Apr 2020 at 06:30, 曾文旌 <wjzeng2012(at)gmail(dot)com> wrote:
>
>
> Do we allow such a bool parameter value? This seems puzzling to me.
>
>
> postgres=# create table t1(c1 int) with(autovacuum_enabled ='tr');
> CREATE TABLE
> postgres=# create table t2(c1 int) with(autovacuum_enabled ='fa');
> CREATE TABLE
> postgres=# \d+ t1
> Table "public.t1"
> Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
> --------+---------+-----------+----------+---------+---------+--------------+-------------
> c1 | integer | | | | plain | |
> Access method: heap
> Options: autovacuum_enabled=tr
>
> [don't post to multiple mailing lists]
>
> I'm not sure it is a bug. It certainly can be an improvement. Code as is does not cause issues although I concur with you that it is at least a strange syntax. It is like this at least since 2009 (commit ba748f7a11e). I'm not sure parse_bool* is the right place to fix it because it could break code. IMHO the problem is that parse_one_reloption() is using the value provided by user; it should test those (abbreviation) conditions and store "true" (for example) as bool value.
>
>
> The document[1] states:
>
> Boolean: Values can be written as on, off, true, false, yes, no, 1, 0
> (all case-insensitive) or any unambiguous prefix of one of these.
>
> Given that PostgreSQL treats such values as boolean values it seems to
> me that it's a normal behavior.
>
> [1] https://www.postgresql.org/docs/devel/config-setting.html
>
>
> Why do table parameters of a bool type have different rules than data types of a Boolean type?
>
>
> postgres=# create table test_bool_type(a bool);
> CREATE TABLE
> postgres=# insert into test_bool_type values(true);
> INSERT 0 1
> postgres=# insert into test_bool_type values(false);
> INSERT 0 1
> postgres=# insert into test_bool_type values('false');
> INSERT 0 1
> postgres=# insert into test_bool_type values('t');
> INSERT 0 1
> postgres=# insert into test_bool_type values('f');
> INSERT 0 1
>
> postgres=# insert into test_bool_type values('tr');
> ERROR: invalid input syntax for type boolean: "tr"
> LINE 1: insert into test_bool_type values('tr');
> ^
> postgres=# insert into test_bool_type values('fa');
> ERROR: invalid input syntax for type boolean: "fa"
> LINE 1: insert into test_bool_type values('fa');
> ^
> postgres=# insert into test_bool_type values('fals');
> ERROR: invalid input syntax for type boolean: "fals"
> LINE 1: insert into test_bool_type values('fals');
>

Hmm that seems strange. In my environment, both 'tr' and 'fa' are
accepted at least with the current HEAD

postgres(1:52514)=# insert into test_bool_type values('tr');
INSERT 0 1
postgres(1:52514)=# insert into test_bool_type values('fa');
INSERT 0 1
postgres(1:52514)=# insert into test_bool_type values('fals');
INSERT 0 1

IIUC both bool of SQL data type and bool of GUC parameter type are
using the same function parse_bool_with_len() to parse the input
value. The behavior can vary depending on the environment?

Regards,

--
Masahiko Sawada http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Hamid Akhtar 2020-04-08 12:27:05 Re: BUG #16350: pgcenter expects postgresql12-libs on postgresql 11
Previous Message Alexey Lesovsky 2020-04-08 12:23:39 Re: BUG #16350: pgcenter expects postgresql12-libs on postgresql 11

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2020-04-08 12:27:39 Re: WIP: WAL prefetch (another approach)
Previous Message Michail Nikolaev 2020-04-08 12:23:42 Re: Thoughts on "killed tuples" index hint bits support on standby