Re: Boolean partitions syntax

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Mark Dilger <hornschnorter(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Boolean partitions syntax
Date: 2018-01-29 05:57:59
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> writes:
> Partition bound literals as captured gram.y don't have any type
> information attached.

Isn't that design broken by definition? TRUE is not the same thing
as 't', nor as 'true'. Nor are 1 and '1' the same thing; it's true
that in some contexts we'll let '1' convert to an integer 1, but the
reverse is not true. Moreover, this approach doesn't have any hope
of ever extending to bound values that aren't bare literals.

I think you are fixing this at the wrong level. Ideally the bound values
ought to be expressions that get coerced to the partition column type.
It's fine to require them to be constants for now, but not to invent
an off-the-cuff set of syntactic restrictions that substitute for the
semantic notion of "must be a constant". That path will lead to nasty
backwards compatibility issues whenever somebody tries to extend the

A concrete example of that is that the code currently accepts:

regression=# create table textpart (a text) partition by list (a);
regression=# create table textpart_t partition of textpart for values in (1);

Since there's no implicit conversion from int to text, this seems
pretty broken to me: there's no way for this behavior to be upward
compatible to an implementation that treats the partition bound
values as anything but text strings. We should fix that before the
behavior gets completely set in concrete.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2018-01-29 06:15:14 Re: list partition constraint shape
Previous Message Ashutosh Bapat 2018-01-29 05:40:14 Re: [HACKERS] PoC: full merge join on comparison clause