|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
|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|