Re: Exclusion constraints on partitioned tables

From: Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Paul Jungwirth <pj(at)illuminatedcomputing(dot)com>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Exclusion constraints on partitioned tables
Date: 2023-03-20 08:24:59
Message-ID: 4467897.LvFx2qVVIh@aivenlaptop
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Le vendredi 17 mars 2023, 17:03:09 CET Paul Jungwirth a écrit :
> I added the code about RTEqualStrategyNumber because that's what we need
> to find an equals operator when the index is GiST (except if it's using
> an opclass from btree_gist; then it needs to be BTEqual again). But then
> I realized that for exclusion constraints we have already figured out
> the operator (in RelationGetExclusionInfo) and put it in
> indexInfo->ii_ExclusionOps. So we can just compare against that. This
> works whether your index uses btree_gist or not.
>
> Here is an updated patch with that change (also rebased).

Thanks ! This looks fine to me like this.

>
> I also included a more specific error message. If we find a matching
> column in the index but with the wrong operator, we should say so, and
> not say there is no matching column.
>

I agree that's a nicer improvement.

Regards,

--
Ronan Dunklau

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2023-03-20 08:32:17 Re: Memory leak from ExecutorState context?
Previous Message Tomas Vondra 2023-03-20 08:19:41 Re: logical decoding and replication of sequences, take 2