Re: [HACKERS] "cannot specify finite value after UNBOUNDED" ... uh, why? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] "cannot specify finite value after UNBOUNDED" ... uh, why?
Date
Msg-id 14003.1496156627@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] "cannot specify finite value after UNBOUNDED" ... uh, why?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] "cannot specify finite value after UNBOUNDED" ... uh, why?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, May 29, 2017 at 3:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Would someone please defend the restrictions imposed by the
>> "seen_unbounded" checks in transformPartitionBound
>> (parse_utilcmd.c:3365..3396 in current HEAD)?

> Because this is supposed to work more or less like row-comparison --
> the earlier columns are strictly more significant than the later ones.
> That is, allowing (1, 2) through (3, 4) allows (2, whatever) but (1,
> y) only if y >= 2 and (3, y) only if y < 4.

I see.  That makes the logic awfully complex though.  I was looking
at get_qual_for_range() yesterday --- it's mind-bendingly complicated
and I have next to no faith that it's 100% right.

> In case you're wondering, this is also how a certain large commercial
> database system interprets composite bounds.  You could imagine in
> theory a system where a bound from (1, 2) to (3, 4) allows only those
> (x, y) where 1<=x<3 and 2<=y<4 but I know of no existing system that
> does anything like that.  If you want that sort of thing, you can get
> it anyway using two levels of partitioning, one on each column.

Well, if we just treated each column independently, you could get
the row-comparison behavior by partitioning on a ROW() expression.
So that argument doesn't impress me.  I suppose compatibility with
other partitioning implementations is worth something, but I'm not
sure it's worth this much complication and risk of bugs.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alexander Sosna
Date:
Subject: [HACKERS] Segmentation fault when creating a BRIN, 10beta1
Next
From: Stephen Frost
Date:
Subject: Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256