> Given that the commit included a test case exercising exactly that,
> I'm not sure why you might think it was unintentional.
Well, maybe not exercising exactly that. No positive test case was
added. The commit replaced a CREATE TABLE fillfactor test case testing
that "30.5" is invalid, with a test case testing that "-30.1" is
out-of-range. I guess that does indirectly test that "-30.1" is not an
improper value, though the out-of-range error means that test case
should really be put in the "-- Fail min/max values check" section and
not in the "-- Fail while setting improper values" section.
My point was that allowing the fractional input really only makes
sense if the "integer" option/GUC has an associated unit. That's why I
questioned whether allowing it in this case (when the integer
option/GUC has no associated unit, like "port" or "max_connections")
was intentional or useful.
> IIRC, the
> reasoning was that we ought to hide whether any given GUC is int or
> float underneath, in anticipation of future changes like caf626b2c.
> Another argument is that in regular SQL, you can assign a fractional
> value to an integer column and the system will let you do it; so
> why not in SET?
>
> In any case, we already shipped that behavior in v12, so I don't think
> we can take it away now. People don't appreciate formerly valid
> settings suddenly not working any more.
>
I guess we'll have to live with the current behaviour then.
Regards,
Greg Nancarrow
Fujitsu Australia
