On Thu, Dec 4, 2014 at 10:46 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > > > Hi, > > > From: Jim Nasby [mailto:jim.na...@bluetreble.com] > > On 12/2/14, 9:43 PM, Amit Langote wrote: > > > > >> >What are you going to do if the partitioning key has two columns of > > >> >different data types? > > >> > > > > Sorry, this totally eluded me. Perhaps, the 'values' needs some more thought. > > They are one of the most crucial elements of the scheme. > > > > > > I wonder if your suggestion of pg_node_tree plays well here. This then could > > be a list of CONSTs or some such... And I am thinking it's a concern only for > > range partitions, no? (that is, a multicolumn partition key) > > > > > > I think partkind switches the interpretation of the field as appropriate. Am I > > missing something? By the way, I had mentioned we could have two values > > fields each for range and list partition kind. > > > > The more SQL way would be records (composite types). That would make > > catalog inspection a LOT easier and presumably make it easier to change the > > partitioning key (I'm assuming ALTER TYPE cascades to stored data). Records > > are stored internally as tuples; not sure if that would be faster than a List of > > Consts or a pg_node_tree. Nodes would theoretically allow using things other > > than Consts, but I suspect that would be a bad idea. > > > > While I couldn’t find an example in system catalogs where a record/composite type is used, there are instances of pg_node_tree at a number of places like in pg_attrdef and others. Could you please point me to such a usage for reference? >
I think you can check the same by manually creating table with a user-defined type. Create type typ as (f1 int, f2 text); Create table part_tab(c1 int, c2 typ); With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
