On Fri, Oct 13, 2017 at 12:34 PM, Alvaro Herrera
<alvherre@alvh.no-ip.org> wrote:
> 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?
I don't think I feel strongly about this, but I'm also not sure
exactly what problem you are trying to solve. Do you want to
elaborate on that a bit?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers