Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-08-08T18:22:36Z
Lists: pgsql-hackers
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
Commits
-
After a MINVALUE/MAXVALUE bound, allow only more of the same.
- e8b65986ba0d 10.0 landed
- 9361f6f54e3f 11.0 landed
-
Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition bounds.
- d363d42bb9a4 10.0 cited