> 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
