On Tue, 7 Apr 2020 at 20:58, Euler Taveira
<euler.taveira@2ndquadrant.com> wrote:
>
> On Tue, 7 Apr 2020 at 06:30, 曾文旌 <wjzeng2012@gmail.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
youthat 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
usingthe 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
Regards,
--
Masahiko Sawada http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
