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: Julien Rouhaud <rjuju123@gmail.com>
Cc: Amit Langote <amitlangote09@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-01-31T21:20:36Z
Lists: pgsql-hackers 
Julien Rouhaud <rjuju123@gmail.com> writes:
> On Sun, Dec 22, 2019 at 10:51 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> While poking at this, I also started to wonder why CheckAttributeType
>> wasn't recursing into ranges, since those are our other kind of
>> container type.  And the answer is that it must, because we allow
>> creation of ranges over composite types:

> While working on regression tests for index collation versioning [1],
> I noticed that the 2nd patch apparently broke the ability to create a
> table using a range over collatable datatype attribute, which we
> apparently don't test anywhere.

Ugh.

> AFAICT, this is only a thinko in CheckAttributeType(), where the range
> collation should be provided rather than the original tuple desc one,
> as per attached.  I also added a create/drop table in an existing
> regression test that was already creating range over collatable type.

Looks good, although I think maybe we'd better test the case a little
harder than this.  Will tweak that and push -- thanks!

			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.