Re: Exclusion constraints on partitioned tables

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Exclusion constraints on partitioned tables
Date: 2023-07-10 14:05:18
Message-ID: e7dba744-d889-3943-e236-4ae39e2927b7@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 09.07.23 03:21, Paul A Jungwirth wrote:
>> It seems to me that many of the test cases added in indexing.sql are
>> redundant with create_table.sql/alter_table.sql (or vice versa). Is
>> there a reason for this?
>
> Yes, there is some overlap. I think that's just because there was
> overlap before, and I didn't want to delete the old tests completely.
> But since indexing.sql has a fuller list of tests and is a superset of
> the others, this new patch removes the redundant tests from
> {create,alter}_table.sql.

This looks better.

> Btw speaking of tests, I want to make sure this new feature will still
> work when you're using btree_gist and and `EXCLUDE WITH (myint =,
> mytsrange &&)` (and not just `(myint4range =, mytsrange &&)`). Some of
> my early attempts writing this patch worked w/o btree_gist but not w/
> (or vice versa). But as far as I know there's no way to test that in
> regress. I wound up writing a private shell script that just does
> this:

> Is there some place in the repo to include a test like that? It seems
> a little funny to put it in the btree_gist suite, but maybe that's the
> right answer.

I'm not sure what value we would get from testing this with btree_gist,
but if we wanted to do that, then adding a new test file to the
btree_gist sql/ directory would seem reasonable to me.

(I would make the test a little bit bigger than you had shown, like
insert a few values.)

If you want to do that, please send another patch. Otherwise, I'm ok to
commit this one.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Önder Kalacı 2023-07-10 14:13:42 Re: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL
Previous Message Sergei Kornilov 2023-07-10 13:56:14 Re: doc: clarify the limitation for logical replication when REPILICA IDENTITY is FULL