Re: Issue with past commit: Allow fractional input values for integer GUCs ...

On Wed, Aug 26, 2020 at 4:47 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> regression=# create table itable (f1 int);
> CREATE TABLE
> regression=# insert into itable values (384.234);
> INSERT 0 1
> regression=# table itable;
> f1
> -----
> 384
> (1 row)
>
> It's always worked like that, and nobody's complained about it.
> I suspect, in fact, that one could find chapter and verse in the
> SQL spec that requires it, just like "numeric" values should get
> rounded if you write too many digits.

That is a bit different from what I had in mind, because it does not
involve a call to int4in(). Instead, it involves a cast. I was
imagining that you would put quotation marks around 384.234, which
does indeed fail:

ERROR: invalid input syntax for type integer: "384.234"

So the question is whether users who supply values for integer-valued
reloptions, or integer-valued GUCs, expect that they will be parsed as
integers, or whether they expect that they will be parsed as float
values and the cast to integers.

While the new behavior seems fine -- and indeed convenient -- for GUCs
that are numeric with a unit, it does not seem very nice at all for
GUCs that are unitless integers. Why do you think that anyone would be
pleased to discover that they can set port = 543.2? We must decide
whether it is more likely that such a setting is the result of a user
error about which we should issue some complaint, or on the other hand
whether the user is hoping that we will be good enough to round the
value off so as to spare them the trouble. My own view is that the
former is vastly more probably than the latter.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company