From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: "cannot specify finite value after UNBOUNDED" ... uh, why?
In-reply-to: 
 <CA+TgmoYoEZHA2GVDqXj=pFA2+RYyPHj-L4sCRMRbya5Y2wdjuQ@mail.gmail.com>
References: <28106.1496041449@sss.pgh.pa.us>
 <CA+TgmoYoEZHA2GVDqXj=pFA2+RYyPHj-L4sCRMRbya5Y2wdjuQ@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Tue, 30 May 2017 10:48:20 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14002.1496156627.1@sss.pgh.pa.us>
Date: Tue, 30 May 2017 11:03:47 -0400
Message-ID: <14003.1496156627@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


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