Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE insteadof UNBOUNDED for range partition b - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE insteadof UNBOUNDED for range partition b
Date
Msg-id CA+Tgmoa2oND8YW=UsbXvE=g5Wq2RFhQN2eRn-jCuo0U5tLeebw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE insteadof UNBOUNDED for range partition b  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead ofUNBOUNDED for range partition b
List pgsql-hackers
On Wed, Sep 13, 2017 at 10:54 AM, Dean Rasheed <dean.a.rasheed@gmail.com> 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
> MINVALUE, so the bounds that we currently support are a strict
> superset of those supported by Oracle and MySQL.
>
> Both Oracle and MySQL allow finite values after MAXVALUE (usually
> listed as "0" in code examples, e.g. see [1]). Oracle explicitly
> documents the fact that values after MAXVALUE are irrelevant in [1].
> I'm not sure if MySQL explicitly documents that, but it does behave
> the same.
>
> Also, both Oracle and MySQL store what the user entered (they do not
> canonicalise), as can be seen by looking at ALL_TAB_PARTITIONS in
> Oracle, or "show create table" in MySQL.

OK, thanks.  I still don't really like allowing this, but I can see
that compatibility with other systems has some value here, and if
nobody else is rejecting these cases, maybe we shouldn't either.  So
I'll hold my nose and change my vote to canonicalizing rather than
rejecting outright.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: [HACKERS] Bug with pg_basebackup and 'shared' tablespace
Next
From: Stephen Frost
Date:
Subject: Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10(upgrading standby servers)