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); 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
