Robert Haas writes:
> 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.
I find that distinction to be entirely without merit; not least because
we also have unitless float
On Wed, Aug 26, 2020 at 4:47 PM Tom Lane 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 i
Robert Haas writes:
> I don't think any of these cases should be allowed. Surely if we
> allowed 384.234 to be inserted into an integer column, everyone would
> say that we'd lost our minds.
regression=# create table itable (f1 int);
CREATE TABLE
regression=# insert into itable values (384.234);
On Mon, Aug 24, 2020 at 5:32 AM Greg Nancarrow wrote:
> For example,
>
> log_file_mode = 384.234
> max_connections = 1.0067e2
> port = 5432.123
> CREATE TABLE ... WITH (fillfactor = 23.45);
> CREATE TABLE ... WITH (parallel_workers = 5.4);
I don't think any of these cases should be allowed. Surel
> 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 te
Greg Nancarrow writes:
> 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).
> ...
> (Is it intentional - or indeed useful - to allow such settings, for
> integer options?)
Given that the commit include
