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

Reply via email to