On Fri, Jul 21, 2017 at 4:24 AM, Dean Rasheed <dean.a.rasheed@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);
CREATE TABLE
rhaas=# create table foo1 partition of foo for values from (minvalue,
0) to (maxvalue, 0);
CREATE TABLE
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