Thread: Real config values for bytes needs quotes?

Hello.

I found it frustrating that the line "shared_buffers = 0.1GB" in
postgresql.conf postgresql.conf was causing an error and that the
value required (additional) surrounding single quotes.  The attached
patch makes the parser accept the use of non-quoted real values
followed by a unit for such variables. I'm not sure if that syntax
fully covers the input syntax of strtod, but I beieve it is suffucient
for most use cases.

Is the following a correct English sentense?

Do you folks think this makes sense?


regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

On 27.02.23 09:32, Kyotaro Horiguchi wrote:
> I found it frustrating that the line "shared_buffers = 0.1GB" in
> postgresql.conf postgresql.conf was causing an error and that the
> value required (additional) surrounding single quotes.  The attached
> patch makes the parser accept the use of non-quoted real values
> followed by a unit for such variables. I'm not sure if that syntax
> fully covers the input syntax of strtod, but I beieve it is suffucient
> for most use cases.

This seems sensible to fix.  If you're not sure about the details, write 
some test cases. :)

At Thu, 2 Mar 2023 11:54:10 +0100, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote in 
> On 27.02.23 09:32, Kyotaro Horiguchi wrote:
> > I found it frustrating that the line "shared_buffers = 0.1GB" in
> > postgresql.conf postgresql.conf was causing an error and that the
> > value required (additional) surrounding single quotes.  The attached
> > patch makes the parser accept the use of non-quoted real values
> > followed by a unit for such variables. I'm not sure if that syntax
> > fully covers the input syntax of strtod, but I beieve it is suffucient
> > for most use cases.
> 
> This seems sensible to fix.  If you're not sure about the details,
> write some test cases. :)

Thanks. I initially intended to limit the change for REAL to accept
units following a value. However, actually I also modified it to
accept '1e1'.

man strtod says it accepts the following format.

> The  expected  form  of the (initial portion of the) string is optional
> leading white space as recognized by isspace(3), an optional plus ('+')
> or  minus  sign  ('-')  and then either (i) a decimal number, or (ii) a
> hexadecimal number, or (iii) an infinity, or (iv) a NAN (not-a-number).
>
> A decimal number consists of a nonempty sequence of decimal digits pos‐
> sibly  containing  a  radix character (decimal point, locale-dependent,
> usually '.'), optionally followed by a  decimal  exponent.   A  decimal
> exponent  consists  of  an  'E' or 'e', followed by an optional plus or
> minus sign, followed by a nonempty  sequence  of  decimal  digits,  and
> indicates multiplication by a power of 10.

It is written in regexp as
'\s*[-+]?(\.\d+|\d+(\.\d*)?)([Ee][-+]?\d+)?'.  The leading whitespace
is unnecessary in this specific usage, and we also need to exclude
INTERGER from this set of matches. Therefore, it should be modified to
'[-+]?((\.\d+|\d+\.\d*)([Ee][-+]?\d+)?|\d+([Ee][-+]?\d+))'.

It is translated to the following BNF notation. UNIT_LETTER is also
needed.

{SIGN}?(("."{DIGIT}+|{DIGIT}+"."{DIGIT}*){EXPONENT}?|{DIGIT}+{EXPONENT}){UNIT_LETTER}*

The attached patch applies aforementioned change to guc-file.l and
includes tests for values in certain patters.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center