Re: should check collations when creating partitioned index

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: should check collations when creating partitioned index
Date: 2023-11-17 20:02:33
Message-ID: f3d6bcc63fdbd80d98ccbef975df5f0a55f58cd9.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2023-11-13 at 10:24 +0100, Peter Eisentraut wrote:
> create table t1 (a int, b text) partition by hash (b);
> create table t1a partition of t1 for values with (modulus 2,
> remainder 0);
> create table t1b partition of t1 for values with (modulus 2,
> remainder 1);
> create unique index i1 on t1 (b collate case_insensitive);
> insert into t1 values (1, 'a'), (2, 'A');  -- this succeeds
>
> The attached patch adds the required collation check.  In the
> example,
> it would not allow the index i1 to be created.

In the patch, you check for an exact collation match. Considering this
case only depends on equality, I think it would be correct if the
requirement was that (a) both collations are deterministic; or (b) the
collations match exactly.

This is related to the discussion here:

https://postgr.es/m/b7a9f32eee8d24518f791168bc6fb653d1f95f4d.camel@j-davis.com

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-11-17 20:13:34 Re: simplehash: preserve consistency in case of OOM
Previous Message Tom Lane 2023-11-17 19:42:00 Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500