Robert Haas wrote:
> Implement table partitioning.
> Currently, tables can be range-partitioned or list-partitioned. List
> partitioning is limited to a single column, but range partitioning can
> involve multiple columns. A partitioning "column" can be an
> expression.
I find the "partition strategy" thing a bit suspect code-wise. I was a
bit bothered by all the "default:" clauses in switches that deal with
the possible values, and I was going to propose simply that we turn that
into an enum -- a trivial patch, I thought. Not so: the way it's used
by the grammar is a bit odd. Apparently, it starts life as a string
(either "list" or "range"), and then transformPartitionSpec() has to go
out of its way to return it as a char.
I propose we have gram.y itself resolve the strings to either 'list' or
'range' and that the node contains only those values, not any string.
Unless there is a reason why things are like this that I'm not seeing?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers