Re: unsupportable composite type partition keys

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Amit Langote <amitlangote09(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: unsupportable composite type partition keys
Date: 2020-02-01 07:46:25
Message-ID: 20200201074625.GA40017@nol
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 31, 2020 at 04:20:36PM -0500, Tom Lane wrote:
> Julien Rouhaud <rjuju123(at)gmail(dot)com> writes:
> > On Sun, Dec 22, 2019 at 10:51 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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!

Ah, I wasn't sure that additional tests on a table would be worthwhile enough.
Thanks for tweaking and pushing!

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pierre Ducroquet 2020-02-01 07:51:04 PATCH: add support for IN and @> in functional-dependency statistics use
Previous Message Kasahara Tatsuhito 2020-02-01 07:05:04 Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read)