[HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDEDfor range partition b
От | Robert Haas |
---|---|
Тема | [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDEDfor range partition b |
Дата | |
Msg-id | CA+Tgmobs+pLPC27tS3gOpEAxAffHrq5w509cvkwTf9pF6cWYbg@mail.gmail.com обсуждение исходный текст |
Ответы |
[HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDEDfor range partition b
|
Список | 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
В списке pgsql-hackers по дате отправления: