Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On Thu, Sep 14, 2017 at 12:59 PM, David G. Johnston wrote: > I think we are being consistent as a project by enforcing strictness of > input in this situation so I'll toss my +0.5/+1 here as well. All right, since all three new votes are going the same direction with

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On Thu, Sep 14, 2017 at 8:41 AM, Stephen Frost wrote: > Robert, all, > > * Robert Haas (robertmh...@gmail.com) wrote: > > > > > > > I vote for rejecting it. DDL compatibility is less valuable than other > > > compatibility. The hypothetical affected application can change

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

Robert, all, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Sep 13, 2017 at 10:49 PM, Noah Misch wrote: > >> > Both Oracle and MySQL allow finite values after MAXVALUE (usually > >> > listed as "0" in code examples, e.g. see [1]). Oracle explicitly > >> > documents the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On 2017/09/14 16:53, Dean Rasheed wrote: > On 13 September 2017 at 10:05, Amit Langote > wrote: >> Coincidentally, I just wrote the patch for canonicalizing stored values, >> instead of erroring out. Please see attached if that's what you were >> thinking too. >> >

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On 13 September 2017 at 14:51, Robert Haas wrote: > Coincidentally, I wrote a patch for this too, but mine goes back to > rejecting MINVALUE or MAXVALUE followed by anything else. > LGTM, if we decide to go this way. One minor review comment -- you missed an example code

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On 13 September 2017 at 10:05, Amit Langote wrote: > Coincidentally, I just wrote the patch for canonicalizing stored values, > instead of erroring out. Please see attached if that's what you were > thinking too. > Looks reasonable to me, if we decide to go this

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On Wed, Sep 13, 2017 at 10:54 AM, Dean Rasheed wrote: > Oracle, MySQL and DB2 all use MINVALUE/MAXVALUE. Actually, Oracle and > MySQL only use MAXVALUE, not MINVALUE, because they don't allow gaps > between partitions and the first partition implicitly starts at >

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On 13 September 2017 at 14:53, Robert Haas wrote: > On Wed, Sep 13, 2017 at 4:51 AM, Dean Rasheed > wrote: >> A drawback to doing this is that we lose compatibility with syntaxes >> supported by other databases, which was part of the reason for

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On Wed, Sep 13, 2017 at 5:05 AM, Amit Langote wrote: >> So thinking about this afresh, my preference would actually be to just >> canonicalise the values stored rather than erroring out. > > Coincidentally, I just wrote the patch for canonicalizing stored values, >

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On Wed, Sep 13, 2017 at 4:51 AM, Dean Rasheed wrote: > 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

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

Hi Dean, On 2017/09/13 17:51, Dean Rasheed wrote: > Robert Haas writes: >> On Tue, Sep 12, 2017 at 9:58 AM, Alvaro Herrera >> wrote: >>> Did anything happen on this, or did we just forget it completely? >> >> I forgot it. :-( >> >> I really

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

Robert Haas writes: > On Tue, Sep 12, 2017 at 9:58 AM, Alvaro Herrera > 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

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

Robert Haas writes: > On Tue, Sep 12, 2017 at 9:58 AM, Alvaro Herrera > wrote: >> Did anything happen on this, or did we just forget it completely? > I forgot it. :-( > I really think we should fix this. +1. You've got the rest of the week

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On Tue, Sep 12, 2017 at 9:58 AM, Alvaro Herrera wrote: > Robert Haas wrote: >> 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

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

Robert Haas wrote: > 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 >

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On 2017/08/09 9:03, David G. Johnston wrote: > On Tue, Aug 8, 2017 at 4:33 PM, Dean Rasheed 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

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On Tue, Aug 8, 2017 at 4:33 PM, Dean Rasheed wrote: > On 8 August 2017 at 19:22, Robert Haas wrote: > > On Fri, Jul 21, 2017 at 4:24 AM, Dean Rasheed > wrote: > >> Also drop the constraint prohibiting finite values