Re: GUC parameters accepts values in both octal and hexadecimalformats - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: GUC parameters accepts values in both octal and hexadecimalformats
Date
Msg-id 20190125233417.GF13803@momjian.us
Whole thread Raw
In response to GUC parameters accepts values in both octal and hexadecimal formats  (Haribabu Kommi <kommi.haribabu@gmail.com>)
List pgsql-hackers
On Tue, Jan  8, 2019 at 05:08:41PM +1100, Haribabu Kommi wrote:
> Hi Hackers,
> 
> The Server GUC parameters accepts values in both Octal and hexadecimal formats
> also.
> 
> postgres=# set max_parallel_workers_per_gather='0x10';
> postgres=# show max_parallel_workers_per_gather;
>  max_parallel_workers_per_gather 
> ---------------------------------
>  16
> 
> postgres=# set max_parallel_workers_per_gather='010';
> postgres=# show max_parallel_workers_per_gather;
>  max_parallel_workers_per_gather 
> ---------------------------------
>  8
> 
> I can check that this behavior exists for quite some time, but I am not able to
> find any documentation related to it? Can some one point me to relevant section
> where it is available? If not exists, is it fine to add it?

Well, we call strtol() in guc.c, and the strtol() manual page says:

    The string may begin with an arbitrary amount of white space (as
    determined by isspace(3)) followed by a single optional '+' or '-' sign.
    If base is zero or 16, the string  may  then include a "0x" prefix, and
    the number will be read in base 16; otherwise, a zero base is taken as
    10 (decimal) unless the next character is '0', in which case it is taken
    as 8 (octal).

so it looks like the behavior is just a side-effect of our strtol call. 
I am not sure it is worth documenting though.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: Alternative to \copy in psql modelled after \g
Next
From: John Naylor
Date:
Subject: Re: WIP: Avoid creation of the free space map for small tables