Re: unsupportable composite type partition keys - Mailing list pgsql-hackers

From Amit Langote
Subject Re: unsupportable composite type partition keys
Date
Msg-id CA+HiwqGiGBgFFcL6YGKRqfX1-gYKmuLLG_JwU_UaSaX2J+jehQ@mail.gmail.com
Whole thread Raw
In response to Re: unsupportable composite type partition keys  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: unsupportable composite type partition keys  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Dec 18, 2019 at 2:12 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Langote <amitlangote09@gmail.com> writes:
> > It seems to me that we currently allow expressions that are anonymous
> > and self-referencing composite type records as partition key, but
> > shouldn't.  Allowing them leads to this:
>
> Hm.  Seems like the restrictions here ought to be just about the same
> as on index columns, no?  That is, it should be roughly a test like
> "no pseudo-types".  The check you're proposing seems awfully specific,
> and I doubt that the equivalent check in CREATE INDEX looks the same.
> (But I didn't go look ... I might be wrong.)

We also need to disallow self-referencing composite type in the case
of partitioning, because otherwise it leads to infinite recursion
shown in my first email.

The timing of building PartitionDesc is what causes it, because the
construction of PartitionBoundInfo in turn requires opening the parent
relation if the partition partition key is of self-referencing
composite type, because we need the TupleDesc when sorting the
partition bounds.  Maybe we'll need to rearrange that someday so that
PartitionDesc is built outside RelationBuildDesc path, so this
infinite recursion doesn't occur, but maybe allowing this case isn't
that useful to begin with?

Thanks,
Amit



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Block level parallel vacuum
Next
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Block level parallel vacuum