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-09T12:14:23Z
Lists: pgsql-hackers
On Tue, Aug 8, 2017 at 7:33 PM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote: > Well perhaps verbosity-reduction isn't sufficient justification but I > still think this is correct because logically any values in the bound > after MINVALUE/MAXVALUE are irrelevant, so it seems overly restrictive > to force all later values to be MINVALUE/MAXVALUE when the code will > just ignore those values. I just don't understand why you think there should be multiple spellings of the same bound. Generally, canonicalization is good. One of my fears here is that at least some people will get confused and think a bound from (minvalue, 0) to (maxvalue, 10) allows any value for the first column and a 0-9 value for the second column which is wrong. My other fear is that, since you've not only allowed this into the syntax but into the catalog, this will become a source of bugs for years to come. Every future patch that deals with partition bounds will now have to worry about testing unbounded-followed-by-non-unbounded. If we're not going to put back those error checks completely - and I think we should - we should at least canonicalize what actually gets stored. -- 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