Re: Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b
Dean Rasheed <dean.a.rasheed@gmail.com>
From: Dean Rasheed <dean.a.rasheed@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>,
Alvaro Herrera <alvherre@alvh.no-ip.org>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-09-13T08:51:12Z
Lists: pgsql-hackers
Attachments
- restore-minvalue-maxvalue-error-checks.patch (application/octet-stream) patch
Robert Haas <robertmhaas@gmail.com> writes: > On Tue, Sep 12, 2017 at 9:58 AM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: >> Did anything happen on this, or did we just forget it completely? > > I forgot it. :-( > > I really think we should fix this. Ah, sorry. This was for me to follow up, and I dropped the ball. Here's a patch restoring the original error checks (actually not the same coding as used in previous versions of the patch, because that would have allowed a MINVALUE after a MAXVALUE and vice versa). A drawback to doing this is that we lose compatibility with syntaxes supported by other databases, which was part of the reason for choosing the terms MINVALUE and MAXVALUE in the first place. So thinking about this afresh, my preference would actually be to just canonicalise the values stored rather than erroring out. Thoughts? Regards, Dean
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