From: Amit Kapila [mailto:amit.kapil...@gmail.com] On Fri, Dec 5, 2014 at 12:27 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > From: Amit Kapila [mailto:amit.kapil...@gmail.com] > On Thu, Dec 4, 2014 at 10:46 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> > wrote: > > > > > 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); > > Is there such a custom-defined type used in some system catalog? Just not > sure how one would put together a custom type to use in a system catalog > given the way a system catalog is created. That's my concern but it may not > be valid. >
> I think you are right. I think in this case we need something similar > to column pg_index.indexprs which is of type pg_node_tree(which > seems to be already suggested by Robert). So may be we can proceed > with this type and see if any one else has better idea. Yeah, with that, I was thinking we may be able to do something like dump a Node that describes the range partition bounds or list of allowed values (say, RangePartitionValues, ListPartitionValues). Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers