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

From Robert Haas
Subject Re: [HACKERS] "cannot specify finite value after UNBOUNDED" ... uh, why?
Date
Msg-id CA+TgmoYoEZHA2GVDqXj=pFA2+RYyPHj-L4sCRMRbya5Y2wdjuQ@mail.gmail.com
Whole thread Raw
In response to [HACKERS] "cannot specify finite value after UNBOUNDED" ... uh, why?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] "cannot specify finite value after UNBOUNDED" ... uh, why?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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)?  They sure look to me like
> nothing but sloppy thinking, and/or protection of downstream sloppy
> thinking.  Why should the boundedness of one partitioning column's
> range matter to any other partitioning column's range?

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.

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.

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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Channel binding support for SCRAM-SHA-256