Re: "cannot specify finite value after UNBOUNDED" ... uh, why?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: "cannot specify finite value after UNBOUNDED" ... uh, why?
Date: 2017-05-30 14:48:20
Message-ID: CA+TgmoYoEZHA2GVDqXj=pFA2+RYyPHj-L4sCRMRbya5Y2wdjuQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 29, 2017 at 3:04 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-05-30 14:50:22 Re: [HACKERS] Channel binding support for SCRAM-SHA-256
Previous Message Bruce Momjian 2017-05-30 14:41:53 Re: Use of non-restart-safe storage by temp_tablespaces