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