Re: On partitioning

On Fri, Dec 5, 2014 at 12:27 PM, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
wrote:
> From: Amit Kapila [mailto:amit(dot)kapila16(at)gmail(dot)com]
> On Thu, Dec 4, 2014 at 10:46 AM, Amit Langote <
Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com