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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] "cannot specify finite value after UNBOUNDED" ... uh, why?
Дата
Msg-id CA+TgmoYoEZHA2GVDqXj=pFA2+RYyPHj-L4sCRMRbya5Y2wdjuQ@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] "cannot specify finite value after UNBOUNDED" ... uh, why?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] "cannot specify finite value after UNBOUNDED" ... uh, why?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Channel binding support for SCRAM-SHA-256