Horton

Re: unsupportable composite type partition keys

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <amitlangote09@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-12-23T14:49:16Z
Lists: pgsql-hackers 
Amit Langote <amitlangote09@gmail.com> writes:
> On Sun, Dec 22, 2019 at 6:13 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> +             * To ensure that it's not leaked completely, re-attach it to the
> +             * new reldesc, or make it a child of the new reldesc's rd_pdcxt
> +             * in the unlikely event that there is one already.  (See hack in
> +             * RelationBuildPartitionDesc.)

> While I can imagine that RelationBuildPartitionDesc() might encounter
> an old partition descriptor making the re-parenting hack necessary
> there, I don't see why it's needed here, because a freshly built
> relation descriptor would not contain the partition descriptor after
> this patch.

Well, as the comment says, that's probably unreachable today.  But
I could see it happening in the future, particularly if we ever allow
partitioned system catalogs.  There are a lot of paths through this
code that are not obvious to the naked eye, and some of them can cause
relcache entries to get populated behind-your-back.  Most of relcache.c
is careful about this; I do not see an excuse for the partition-data
code to be less so, even if we think it can't happen today.

(I notice that RelationBuildPartitionKey is making a similar assumption
that the partkey couldn't magically appear while it's working, and I
don't like it much there either.)

>> * It'd be better to declare RelationGetPartitionKey and
>> RelationGetPartitionDesc in relcache.h and get their callers out of the
>> business of including rel.h, where possible.

> Although I agree to declare them in relcache.h, that doesn't reduce
> the need to include rel.h in their callers much, because anyplace that
> uses RelationGetPartitionDesc() is also very likely to use
> RelationGetRelid() which is in rel.h.

Hm.  Well, we can try anyway.

> [1] https://www.postgresql.org/message-id/CA%2BHiwqFucUh7hYkfZ6x1MVcs_R24eUfNVuRwdE_FwuwK8XpSZg%40mail.gmail.com

Oh, interesting --- I hadn't been paying much attention to that thread.
I'll compare your PoC there to what I did.

			regards, tom lane

Commits

  1. Fix CheckAttributeType's handling of collations for ranges.

  2. Improve comments in utils/rel.h.

  3. Allow whole-row Vars to be used in partitioning expressions.

  4. Remove equalPartitionDescs().

  5. Load relcache entries' partitioning data on-demand, not immediately.

  6. Disallow partition key expressions that return pseudo-types.

  7. Prevent a rowtype from being included in itself via a range.