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

From Stephen Frost
Subject Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE insteadof UNBOUNDED for range partition b
Date
Msg-id 20170914154117.GG4628@tamriel.snowman.net
Whole thread Raw
In response to [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead ofUNBOUNDED for range partition b  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE insteadof UNBOUNDED for range partition b  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-hackers
Robert, all,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Wed, Sep 13, 2017 at 10:49 PM, Noah Misch <noah@leadboat.com> 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 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.
> >
> > I vote for rejecting it.  DDL compatibility is less valuable than other
> > compatibility.  The hypothetical affected application can change its DDL to
> > placate PostgreSQL and use that modified DDL for all other databases, too.
>
> OK.  Any other votes?

I think I side with Noah on this one.  I agree that DDL compatibility is
less valuable than other compatibility.  I had also been thinking that
perhaps it would be good to still be compatible for the sake of DBAs not
being confused if they got an error, but this seems straight-forward
enough that it wouldn't take much for a DBA who is building such
partitions to understand their mistake and to fix it.

I haven't been as close to this as others, so perhaps my vote is only
0.5 on this specific case, but that's my feeling on it.

Also, I don't think we should be adding compatibility for the sake of
compatibility alone.  If there's more than one way to do something and
they're all correct and reasonable, then I could see us choosing the
route that matches what others in the industry do, but I don't see
simply ignoring user input in this specific case as really correct and
therefore it's better to reject it.

Basically, for my 2c, the reason Oracle does this is something more of a
historical artifact than because it was deemed sensible, and everyone
else just followed suit, but I don't believe we need to or should.

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Jesper Pedersen
Date:
Subject: Re: [HACKERS] [POC] hash partitioning
Next
From: Simon Riggs
Date:
Subject: Re: [HACKERS] Surjective functional indexes