Issue with past commit: Allow fractional input values for integer GUCs ... - Mailing list pgsql-hackers

From Greg Nancarrow
Subject Issue with past commit: Allow fractional input values for integer GUCs ...
Date
Msg-id CAJcOf-fPKdMwORHzK9xx2HaS=YKkz=fdQHXK=A_6c+or6Trbqg@mail.gmail.com
Whole thread Raw
Responses Re: Issue with past commit: Allow fractional input values for integer GUCs ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Issue with past commit: Allow fractional input values for integer GUCs ...  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi Hackers,

I may be wrong, but an issue seems to have been introduced by the
following commit (March 11, 2019):

    Allow fractional input values for integer GUCs, and improve rounding logic
    https://github.com/postgres/postgres/commit/1a83a80a2fe5b559f85ed4830acb92d5124b7a9a

The changes made allow fractional input for some cases where I believe
it shouldn't be allowed (i.e. when the setting does not accept a
unit).
For example,

log_file_mode = 384.234
max_connections = 1.0067e2
port = 5432.123

(Is it intentional - or indeed useful - to allow such settings, for
integer options?)

Also, the modified parse_int() function is used for parsing other
options, such as the integer storage parameters for CREATE TABLE and
CREATE INDEX. For example, the following integer parameter settings
are currently allowed but I don't believe that they should be:

CREATE TABLE ... WITH (fillfactor = 23.45);
CREATE TABLE ... WITH (parallel_workers = 5.4);


I have attached a patch with a proposed correction, keeping it a
simple change to the existing parse_int() function, rather than making
further changes for more optimal integer parsing code. The patch also
updates a couple of test cases (reverting one to its original state
before the commit mentioned above).

Let me know what you think.

Regards,
Greg Nancarrow
Fujitsu Australia

Attachment

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [POC] Fast COPY FROM command for the table with foreign partitions
Next
From: Amul Sul
Date:
Subject: Re: new heapcheck contrib module