On Fri, Jul 21, 2017 at 4:24 AM, Dean Rasheed <dean.a.rash...@gmail.com> wrote:
> Also drop the constraint prohibiting finite values after an unbounded
> column, and just document the fact that any values after MINVALUE or
> MAXVALUE are ignored. Previously it was necessary to repeat UNBOUNDED
> multiple times, which was needlessly verbose.

I would like to (belatedly) complain about this part of this commit.
Now you can do stuff like this:

rhaas=# create table foo (a int, b text) partition by range (a, b);
rhaas=# create table foo1 partition of foo for values from (minvalue,
0) to (maxvalue, 0);

The inclusion of 0 has no effect, but it is still stored in the
catalog, shows up in \d foo1, and somebody might think it does
something.  I think we should go back to requiring bounds after
minvalue or maxvalue to be minvalue or maxvalue.  I thought maybe the
idea here was that you were going to allow something like this to
work, which actually would have saved some typing:

create table foo2 partition of foo for values from (minvalue) to (maxvalue);

But no:

ERROR:  FROM must specify exactly one value per partitioning column

So the only way that this has made things less verbose is by letting
you put in a meaningless value of the data type which takes fewer than
8 characters to type.  That doesn't seem to me to be a defensible way
of reducing verbosity.

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to