On Fri, Oct 13, 2017 at 12:34 PM, Alvaro Herrera <alvhe...@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