Re: Boolean partitions syntax

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
feature.

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

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

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