Thread
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix WITHOUT OVERLAPS' interaction with domains.
- 4edd6036d69c 19 (unreleased) landed
- 49f3cb453b9b 18.4 landed
-
domain for WITHOUT OVERLAPS
jian he <jian.universality@gmail.com> — 2025-12-03T07:38:56Z
hi. While working on domain IS JSON, I found out that WITHOUT OVERLAPS does not support for domain too. but it does support user-defined range types (via CREATE TYPE). after looking around: check_exclusion_or_unique_constraint->ExecWithoutOverlapsNotEmpty ExecWithoutOverlapsNotEmpty typtype should be domain's basetype's typtype otherwise it will fallback to: elog(ERROR, "WITHOUT OVERLAPS column \"%s\" is not a range or multirange", NameStr(attname)); That means we need to cheaply get the domain basetype's pg_type.typtype in lookup_type_cache. so I added a new char field: TypeCacheEntry.domainBaseTyptype. it should be working: For primary key, unique constraint: pg_index.indclass is the same for domain and basetype. no need to worry too much about pg_index.indcollation because range type is not collateable. For foreign key: pg_constraint (conpfeqop, conppeqop, conffeqop) are the same for domain and basetype. -- jian https://www.enterprisedb.com/ -
Re: domain for WITHOUT OVERLAPS
Paul A Jungwirth <pj@illuminatedcomputing.com> — 2025-12-03T18:39:40Z
On Tue, Dec 2, 2025 at 11:39 PM jian he <jian.universality@gmail.com> wrote: > > While working on domain IS JSON, I found out that > WITHOUT OVERLAPS does not support for domain too. > but it does support user-defined range types (via CREATE TYPE). > > after looking around: > check_exclusion_or_unique_constraint->ExecWithoutOverlapsNotEmpty > ExecWithoutOverlapsNotEmpty typtype should be domain's basetype's typtype > otherwise it will fallback to: > elog(ERROR, "WITHOUT OVERLAPS column \"%s\" is not a range > or multirange", > NameStr(attname)); > > That means we need to cheaply get the domain basetype's > pg_type.typtype in lookup_type_cache. > so I added a new char field: TypeCacheEntry.domainBaseTyptype. Thanks for the bug report and fix! Have you created a commitfest entry for this? I didn't find one. +CREATE DOMAIN d_textrange1 AS int4range CHECK (VALUE <> '[10,10]'); +CREATE DOMAIN d_textrange2 AS textrange2 CHECK (VALUE <> '[c,c]'); +CREATE DOMAIN d_textrange2c AS d_textrange2; The first domain should be called d_int4range or d_int4range1, right? Also let's name them like int4range_d so that we can use int4_d_range for a range over a domain. Please use closed/open notation to match the rest of the ranges in the file: '[10,11)' and '[c,d)'. I think there are these cases to consider: - WITHOUT OVERLAPS on a rangetype whose subtype has a domain - WITHOUT OVERLAPS on a rangetype with a domain on itself - WITHOUT OVERLAPS on a multirangetype whose subtype has a domain - WITHOUT OVERLAPS on a multirangetype whose rangetype has a domain - WITHOUT OVERLAPS on a multirangetype with a domain on itself For instance we could set things up like so: -- range+multirange over a domain: create domain int4_d as integer check (value <> 10); create type int4_d_range as range (subtype = int4_d); -- domain on a range: create domain int4range_d as int4range check (value <> '[10,11)'); -- domain on a multirange: create domain int4multirange_d as int4multirange check (value <> '{[10,11)}'); Then we have this: ``` [v19devel:5432][426675] postgres=# select oid, typname, typtype, typbasetype, typtypmod from pg_type where oid >= 20000 order by oid ; oid | typname | typtype | typbasetype | typtypmod -------+--------------------+---------+-------------+----------- 24595 | _int4_d | b | 0 | -1 24596 | int4_d | d | 23 | -1 24598 | _int4_d_range | b | 0 | -1 24599 | int4_d_multirange | m | 0 | -1 24600 | _int4_d_multirange | b | 0 | -1 24601 | int4_d_range | r | 0 | -1 24608 | _int4range_d | b | 0 | -1 24609 | int4range_d | d | 3904 | -1 24611 | _int4multirange_d | b | 0 | -1 24612 | int4multirange_d | d | 4451 | -1 ``` Note that creating a domain on a range does not create a corresponding multirange. Maybe that is a bug. It means we can't test the 4th case above. It looks like domains on the subtype work, but not directly on a range or multirange: ``` [v19devel:5432][426675] postgres=# create table t1 (id int4range, valid_at int4_d_range, primary key (id, valid_at without overlaps)); CREATE TABLE [v19devel:5432][426675] postgres=# create table t2 (id int4range, valid_at int4range_d, primary key (id, valid_at without overlaps)); ERROR: column "valid_at" in WITHOUT OVERLAPS is not a range or multirange type LINE 1: ...ate table t2 (id int4range, valid_at int4range_d, primary ke... ^ [v19devel:5432][426675] postgres=# create table t3 (id int4range, valid_at int4_d_multirange, primary key (id, valid_at without overlaps)); CREATE TABLE [v19devel:5432][426675] postgres=# create table t4 (id int4range, valid_at int4_multirange_d, primary key (id, valid_at without overlaps)); ERROR: type "int4_multirange_d" does not exist LINE 1: create table t4 (id int4range, valid_at int4_multirange_d, p... ``` It would be good to have tests for all of those. For instance: ``` -- domain on a multirange: CREATE DOMAIN textmultirange2_d AS textmultirange2 CHECK (VALUE <> '{[c,d)}'); CREATE TABLE temporal_mltrng4 ( id d_int4range1, valid_at textmultirange2_d, CONSTRAINT temporal_rng4_pk PRIMARY KEY (id, valid_at WITHOUT OVERLAPS) ); INSERT INTO temporal_mltrng4 VALUES ('[1,2)', '{[c,d)}'); --domain constraint violation INSERT INTO temporal_mltrng4 VALUES ('[1,2)', '{[a,g)}'); INSERT INTO temporal_mltrng4 VALUES ('[1,2)', '{[b,c)}'); --error INSERT INTO temporal_mltrng4 VALUES ('[2,3)', '{[B,C)}'), ('[2,2]', '{[A,C)}'); --error CREATE TABLE temporal_mltrngfk (parent_id d_int4range1, id int4range, valid_at textmultirange2_d); ALTER TABLE temporal_mltrngfk ADD CONSTRAINT temporal_mltrngfk_fk FOREIGN KEY (parent_id, PERIOD valid_at) REFERENCES temporal_mltrng4; INSERT INTO temporal_mltrngfk VALUES ('[1,2)', '[2,3)', '{[d,e)}'); TABLE temporal_mltrng4; TABLE temporal_mltrngfk; UPDATE temporal_mltrng4 SET valid_at = '{[c,d)}'; --error UPDATE temporal_mltrng4 SET valid_at = '{[a,h)}'; UPDATE temporal_mltrng4 SET valid_at = '{[f,g)}'; --error DROP TABLE temporal_mltrng4, temporal_mltrngfk; ``` When I try that, it looks like your patch fixes multiranges too. Yours, -- Paul ~{:-) pj@illuminatedcomputing.com -
Re: domain for WITHOUT OVERLAPS
jian he <jian.universality@gmail.com> — 2025-12-11T04:23:07Z
On Thu, Dec 4, 2025 at 2:39 AM Paul A Jungwirth <pj@illuminatedcomputing.com> wrote: > > I think there are these cases to consider: > > - WITHOUT OVERLAPS on a rangetype whose subtype has a domain > - WITHOUT OVERLAPS on a rangetype with a domain on itself > - WITHOUT OVERLAPS on a multirangetype whose subtype has a domain > - WITHOUT OVERLAPS on a multirangetype whose rangetype has a domain > - WITHOUT OVERLAPS on a multirangetype with a domain on itself > hi. please check the attached polished test. (no C code change). I think the test I am missing is > - WITHOUT OVERLAPS on a multirangetype whose rangetype has a domain because it expects CREATE DOMAIN also to create a multirange type for rangetype. but currently we didn't do it. -- jian https://www.enterprisedb.com
-
Re: domain for WITHOUT OVERLAPS
Paul A Jungwirth <pj@illuminatedcomputing.com> — 2025-12-23T03:25:46Z
On Wed, Dec 10, 2025 at 8:23 PM jian he <jian.universality@gmail.com> wrote: > polished tests for > > - WITHOUT OVERLAPS on a rangetype whose subtype has a domain > > - WITHOUT OVERLAPS on a rangetype with a domain on itself > > - WITHOUT OVERLAPS on a multirangetype whose subtype has a domain > > - WITHOUT OVERLAPS on a multirangetype whose rangetype has a domain > > - WITHOUT OVERLAPS on a multirangetype with a domain on itself > > no tests for > > - WITHOUT OVERLAPS on a multirangetype whose rangetype has a domain > now. > > because the expected behavior assumes that CREATE DOMAIN also generates a > corresponding multirange type for the domain range type, which is not true. > > --example, we expect create domain also create a multirange type for xxint4 > CREATE DOMAIN xxint4 AS int4range CHECK (VALUE <> '[10,11)'); > SELECT typname FROM pg_type WHERE typname ~* 'xxint4'; I'm not sure whether creating a domain on a range should create a multirange or not. I asked the list on another thread. Since it does not create a new range constructor either (or an entry in pg_range), maybe not creating a new multirange is correct. Anyway I think we can fix the WITHOUT OVERLAPS issue without dealing with that. > diff --git a/src/backend/utils/cache/typcache.c b/src/backend/utils/cache/typcache.c > index 6a347698edf..e27ca1466f2 100644 > --- a/src/backend/utils/cache/typcache.c > +++ b/src/backend/utils/cache/typcache.c > @@ -944,6 +944,8 @@ lookup_type_cache(Oid type_id, int flags) > typentry->domainBaseTypmod = -1; > typentry->domainBaseType = > getBaseTypeAndTypmod(type_id, &typentry->domainBaseTypmod); > + typentry->domainBaseTyptype = > + get_typtype(typentry->domainBaseType); > } > if ((flags & TYPECACHE_DOMAIN_CONSTR_INFO) && > (typentry->flags & TCFLAGS_CHECKED_DOMAIN_CONSTRAINTS) == 0 && Is there any performance concern about adding this lookup? >From what I can tell we don't use TYPECACHE_DOMAIN_BASE_INFO very often, so it is probably okay. We can get here in the executor from ExecEvalWholeRowVar, but that seems acceptable to me. > +-- > +-- tests for range over domain, multirange over a domain, custom range type over > +-- domain. > +-- > +CREATE DOMAIN int4_d as integer check (value <> 10); > +CREATE TYPE int4_d_range as range (subtype = int4_d); > +CREATE DOMAIN int4multirange_d as int4multirange check (value <> '{[10,11)}'); > +CREATE DOMAIN d_int4range1 AS int4range CHECK (VALUE <> '[10,11)'); > +CREATE DOMAIN d_textrange2 AS textrange2 CHECK (VALUE <> '[c,d)'); > +CREATE DOMAIN d_textrange2c AS d_textrange2; > +CREATE DOMAIN textmultirange2_d AS textmultirange2 CHECK (VALUE <> '{[c,d)}'); The comment doesn't seem to match. It mentions three scenarios, but I'm seeing: - int4_d_range is a range over a domain. - int4multirange_d is a domain over a multirange. - d_int4range1 is a domain over a range. - d_textrange2 is a domain over a custom range. - d_textrange2c is a domain over a domain, with no extra constraint. What is this one for? - textmultirange2_d is a domain over a custom multirange. I think the naming is confusing. Sometimes you prepend "d_" and sometimes you append "_d". Consistency helps here because I can infer what the name means without having to look it up. What do you think of always appending "_d"? Why "d_int4range1"? I don't see a "d_int4range2". > +CREATE TABLE temporal_rng4mrng ( > + id d_int4range1, > + valid_at int4multirange_d, > + CONSTRAINT temporal_rng4_pk PRIMARY KEY (id, valid_at WITHOUT OVERLAPS) > +); > +INSERT INTO temporal_rng4mrng VALUES ('[1,2)', '{[10,11)}'); --error > +ERROR: value for domain int4multirange_d violates check constraint "int4multirange_d_check" > +INSERT INTO temporal_rng4mrng VALUES ('[1,2)', '{[10,13)}'), ('[1,2)', '{[2,13)}'); --error > +ERROR: conflicting key value violates exclusion constraint "temporal_rng4_pk" > +DETAIL: Key (id, valid_at)=([1,2), {[2,13)}) conflicts with existing key (id, valid_at)=([1,2), {[10,13)}). > +DROP TABLE temporal_rng4mrng; Okay, so we test a domain over a multirange here. I don't understand the table name temporal_rng4mrng. It might be a typo for temporal_mltrng4? > +CREATE TABLE temporal_rng4 ( > + id d_int4range1, > + id1 int4_d_range, > + valid_at d_textrange2c, > + CONSTRAINT temporal_rng4_pk PRIMARY KEY (id, id1, valid_at WITHOUT OVERLAPS) > +); > +INSERT INTO temporal_rng4 VALUES ('[1,2)', '[1,2)', '[c,d)'); --error > +ERROR: value for domain d_textrange2c violates check constraint "d_textrange2_check" > +INSERT INTO temporal_rng4 VALUES ('[1,2)', '[10,12)', '[a,g)'); --error > +ERROR: value for domain int4_d violates check constraint "int4_d_check" > +LINE 1: INSERT INTO temporal_rng4 VALUES ('[1,2)', '[10,12)', '[a,g)... > + ^ Here we test a domain over a custom rangetype (d_textrange2c). Does using domains for the non-WITHOUT OVERLAPS parts add anything to this test? Or should we have separate tests where those are in the WITHOUT OVERLAPS position? We get a line number for the second failure above but not the first. Is that something we can fix? > +CREATE TABLE temporal_rngfk ( > + parent_id d_int4range1, > + id int4range, > + id1 int4_d_range, > + valid_at d_textrange2); > +ALTER TABLE temporal_rngfk > + ADD CONSTRAINT temporal_rngfk_fk > + FOREIGN KEY (parent_id, id1, PERIOD valid_at) > + REFERENCES temporal_rng4; > +INSERT INTO temporal_rngfk VALUES ('[1,2)', '[2,3)', '[9,11)', '[d,e)'); > +TABLE temporal_rng4; > + id | id1 | valid_at > +-------+--------+---------- > + [1,2) | [9,11) | [a,g) > +(1 row) > + > +TABLE temporal_rngfk; > + parent_id | id | id1 | valid_at > +-----------+-------+--------+---------- > + [1,2) | [2,3) | [9,11) | [d,e) > +(1 row) > + > +UPDATE temporal_rng4 SET valid_at = '[c,d)'; --error > +ERROR: value for domain d_textrange2c violates check constraint "d_textrange2_check" > +UPDATE temporal_rng4 SET valid_at = '[a,h)'; > +UPDATE temporal_rng4 SET valid_at = '[f,g)'; --error > +ERROR: update or delete on table "temporal_rng4" violates foreign key constraint "temporal_rngfk_fk" on table "temporal_rngfk" > +DETAIL: Key (id, id1, valid_at)=([1,2), [9,11), [a,h)) is still referenced from table "temporal_rngfk". > +DROP TABLE temporal_rng4, temporal_rngfk; Here we test foreign keys with a domain over a custom rangetype. Again I'm not sure it adds anything to add int4_d_range. What about a domain referencing a non-domain and a non-domain referencing a domain (in the WITHOUT OVERLAPS position)? We allow that for regular FK parts, so we should allow it for the WITHOUT OVERLAPS part as well. > +-- domain on a multirange > +CREATE TABLE temporal_mltrng4 ( > + id d_int4range1, > + valid_at textmultirange2_d, > + CONSTRAINT temporal_rng4_pk PRIMARY KEY (id, valid_at WITHOUT OVERLAPS) > +); > +INSERT INTO temporal_mltrng4 VALUES ('[1,2)', '{[c,d)}'); --error > +ERROR: value for domain textmultirange2_d violates check constraint "textmultirange2_d_check" > +INSERT INTO temporal_mltrng4 VALUES ('[1,2)', '{[a,g)}'); > +INSERT INTO temporal_mltrng4 VALUES ('[1,2)', '{[b,c)}'); --error > +ERROR: conflicting key value violates exclusion constraint "temporal_rng4_pk" > +DETAIL: Key (id, valid_at)=([1,2), {[b,c)}) conflicts with existing key (id, valid_at)=([1,2), {[a,g)}). > +INSERT INTO temporal_mltrng4 VALUES ('[2,3)', '{[B,C)}'), ('[2,3)', '{[A,C)}'); --error > +ERROR: conflicting key value violates exclusion constraint "temporal_rng4_pk" > +DETAIL: Key (id, valid_at)=([2,3), {[A,C)}) conflicts with existing key (id, valid_at)=([2,3), {[B,C)}). > +CREATE TABLE temporal_mltrngfk (parent_id d_int4range1, id int4range, > +valid_at textmultirange2_d); > +ALTER TABLE temporal_mltrngfk > + ADD CONSTRAINT temporal_mltrngfk_fk > + FOREIGN KEY (parent_id, PERIOD valid_at) > + REFERENCES temporal_mltrng4; > +INSERT INTO temporal_mltrngfk VALUES ('[1,2)', '[2,3)', '{[d,e)}'); > +TABLE temporal_mltrng4; > + id | valid_at > +-------+---------- > + [1,2) | {[a,g)} > +(1 row) > + > +TABLE temporal_mltrngfk; > + parent_id | id | valid_at > +-----------+-------+---------- > + [1,2) | [2,3) | {[d,e)} > +(1 row) > + > +UPDATE temporal_mltrng4 SET valid_at = '{[c,d)}'; --error > +ERROR: value for domain textmultirange2_d violates check constraint "textmultirange2_d_check" > +UPDATE temporal_mltrng4 SET valid_at = '{[a,h)}'; > +UPDATE temporal_mltrng4 SET valid_at = '{[f,g)}'; --error > +ERROR: update or delete on table "temporal_mltrng4" violates foreign key constraint "temporal_mltrngfk_fk" on table "temporal_mltrngfk" > +DETAIL: Key (id, valid_at)=([1,2), {[a,h)}) is still referenced from table "temporal_mltrngfk". > +DROP TABLE temporal_mltrng4, temporal_mltrngfk; This is similar to the test above using table temporal_rng4mrng. The only difference is that the multirange uses a custom range type. That's great, but maybe the comment can express that, and the two test groups could be adjacent? > @@ -309,6 +419,27 @@ CREATE TABLE temporal_rng3 ( > ); > ALTER TABLE temporal_rng3 DROP CONSTRAINT temporal_rng3_uq; > DROP TABLE temporal_rng3; > +CREATE TABLE temporal_rng4 ( > + id d_int4range1, > + valid_at d_textrange2c, > + CONSTRAINT temporal_rng4_pk UNIQUE (id, valid_at WITHOUT OVERLAPS) > +); > +INSERT INTO temporal_rng4 VALUES ('[1,2)', NULL), (NULL, '[1,2)'); > +INSERT INTO temporal_rng4 VALUES ('[1,2)', '[c,d)'); --error > +ERROR: value for domain d_textrange2c violates check constraint "d_textrange2_check" > +INSERT INTO temporal_rng4 VALUES ('[1,2)', '[a,d)'); > +INSERT INTO temporal_rng4 VALUES ('[1,2)', '[b,c)'); --error > +ERROR: conflicting key value violates exclusion constraint "temporal_rng4_pk" > +DETAIL: Key (id, valid_at)=([1,2), [b,c)) conflicts with existing key (id, valid_at)=([1,2), [a,d)). > +INSERT INTO temporal_rng4 VALUES ('[10,11)', NULL); --error > +ERROR: value for domain d_int4range1 violates check constraint "d_int4range1_check" > +INSERT INTO temporal_rng4 VALUES ('[2,3)', '[B,C)'), ('[2,3)', '[A,C)'); --error > +ERROR: conflicting key value violates exclusion constraint "temporal_rng4_pk" > +DETAIL: Key (id, valid_at)=([2,3), [A,C)) conflicts with existing key (id, valid_at)=([2,3), [B,C)). > +DROP TABLE temporal_rng4; > +DROP TYPE int4_d_range; > +DROP DOMAIN d_int4range1, d_textrange2c, d_textrange2, > + textmultirange2_d, int4multirange_d, int4_d; > DROP TYPE textrange2; > -- > -- test ALTER TABLE ADD CONSTRAINT Here we test a domain over a custom rangetype. Great! But again a comment explaining the intent would be good. The order of the new test groups seems odd to me. I would have expected to go from simple to complex, e.g. domain over range, domain over custom range, domain over multirange, domain over custom multirange. Also testing a range over a domain (in WITHOUT OVERLAPS position) would be good. Yours, -- Paul ~{:-) pj@illuminatedcomputing.com -
Re: domain for WITHOUT OVERLAPS
Paul A Jungwirth <pj@illuminatedcomputing.com> — 2025-12-23T18:08:19Z
On Mon, Dec 22, 2025 at 7:25 PM Paul A Jungwirth <pj@illuminatedcomputing.com> wrote: > > On Wed, Dec 10, 2025 at 8:23 PM jian he <jian.universality@gmail.com> wrote: > > +-- tests for range over domain, multirange over a domain, custom range type over > > +-- domain. > > +-- > > +CREATE DOMAIN int4_d as integer check (value <> 10); > > +CREATE TYPE int4_d_range as range (subtype = int4_d); > > +CREATE DOMAIN int4multirange_d as int4multirange check (value <> '{[10,11)}'); > > +CREATE DOMAIN d_int4range1 AS int4range CHECK (VALUE <> '[10,11)'); > > +CREATE DOMAIN d_textrange2 AS textrange2 CHECK (VALUE <> '[c,d)'); > > +CREATE DOMAIN d_textrange2c AS d_textrange2; > > +CREATE DOMAIN textmultirange2_d AS textmultirange2 CHECK (VALUE <> '{[c,d)}'); > > The comment doesn't seem to match. It mentions three scenarios, but I'm seeing: > > - int4_d_range is a range over a domain. > - int4multirange_d is a domain over a multirange. > - d_int4range1 is a domain over a range. > - d_textrange2 is a domain over a custom range. > - d_textrange2c is a domain over a domain, with no extra constraint. > What is this one for? > - textmultirange2_d is a domain over a custom multirange. Another variation I'm not seeing tested yet is a multirange over a domain. In other words what ranges call the "subtype" is a domain. Such a multirange is already created by these lines: > > +CREATE DOMAIN int4_d as integer check (value <> 10); > > +CREATE TYPE int4_d_range as range (subtype = int4_d); For example we can use it: [v19devel:5432][454113] postgres=# select '{[1,2)}'::int4_d_multirange; int4_d_multirange ------------------- {[1,2)} (1 row) [v19devel:5432][454113] postgres=# select '{[10,12)}'::int4_d_multirange; ERROR: value for domain int4_d violates check constraint "int4_d_check" LINE 1: select '{[10,12)}'::int4_d_multirange; ^ So it seems worthwhile to test WITHOUT OVERLAPS with that variation as well. Yours, -- Paul ~{:-) pj@illuminatedcomputing.com -
Re: domain for WITHOUT OVERLAPS
jian he <jian.universality@gmail.com> — 2025-12-29T07:17:42Z
On Tue, Dec 23, 2025 at 11:25 AM Paul A Jungwirth <pj@illuminatedcomputing.com> wrote: > > > diff --git a/src/backend/utils/cache/typcache.c b/src/backend/utils/cache/typcache.c > > index 6a347698edf..e27ca1466f2 100644 > > --- a/src/backend/utils/cache/typcache.c > > +++ b/src/backend/utils/cache/typcache.c > > @@ -944,6 +944,8 @@ lookup_type_cache(Oid type_id, int flags) > > typentry->domainBaseTypmod = -1; > > typentry->domainBaseType = > > getBaseTypeAndTypmod(type_id, &typentry->domainBaseTypmod); > > + typentry->domainBaseTyptype = > > + get_typtype(typentry->domainBaseType); > > } > > if ((flags & TYPECACHE_DOMAIN_CONSTR_INFO) && > > (typentry->flags & TCFLAGS_CHECKED_DOMAIN_CONSTRAINTS) == 0 && > > Is there any performance concern about adding this lookup? > From what I can tell we don't use TYPECACHE_DOMAIN_BASE_INFO very > often, so it is probably okay. > We can get here in the executor from ExecEvalWholeRowVar, but that > seems acceptable to me. > > hi. To make WITHOUT OVERLAPS work with domains, ExecWithoutOverlapsNotEmpty requires the base type’s typtype. I do not see a viable alternative approach. We can cache the base type's typtype in TypeCacheEntry->domainBaseTyptype. ``` if ((flags & TYPECACHE_DOMAIN_BASE_INFO) && typentry->domainBaseType == InvalidOid && typentry->typtype == TYPTYPE_DOMAIN) { typentry->domainBaseTypmod = -1; typentry->domainBaseType = getBaseTypeAndTypmod(type_id, &typentry->domainBaseTypmod); typentry->domainBaseTyptype = get_typtype(typentry->domainBaseType); } ``` We look up the domain base type’s typtype only once. On subsequent lookup_type_cache call, typentry->domainBaseType already is a valid OID, so the IF branch above will not be reached. so. I don't see any performance issues here. > > Also testing a range over a domain (in WITHOUT OVERLAPS position) would be good. > I do not think we need extensive foreign key–related tests, because check_exclusion_or_unique_constraint is only invoked for data changes on the primary key side. So, I kept only a single foreign key–related test. The attached patch should address all of your comments. I think you will like attached regress tests. -- jian https://www.enterprisedb.com/ -
Re: domain for WITHOUT OVERLAPS
Paul A Jungwirth <pj@illuminatedcomputing.com> — 2026-02-11T18:50:49Z
On Sun, Dec 28, 2025 at 11:18 PM jian he <jian.universality@gmail.com> wrote: > > > Is there any performance concern about adding this lookup? > > From what I can tell we don't use TYPECACHE_DOMAIN_BASE_INFO very > > often, so it is probably okay. > > We can get here in the executor from ExecEvalWholeRowVar, but that > > seems acceptable to me. > > > > > hi. > > To make WITHOUT OVERLAPS work with domains, ExecWithoutOverlapsNotEmpty requires > the base type’s typtype. I do not see a viable alternative approach. > > We can cache the base type's typtype in TypeCacheEntry->domainBaseTyptype. Okay. > > > > Also testing a range over a domain (in WITHOUT OVERLAPS position) would be good. > > > I do not think we need extensive foreign key–related tests, because > check_exclusion_or_unique_constraint is only invoked for data changes on the > primary key side. So, I kept only a single foreign key–related test. The foreign key code also uses the column type, so there are still interesting feature combinations here that should be tested rather than just assuming they work. > The attached patch should address all of your comments. > I think you will like attached regress tests. A lot of the issues I mentioned before don't look addressed to me. What do you think of the v4 patch attached here? It includes a few more FK tests. Some other details I changed: +-- +-- tests for range over domain, multirange over a domain, custom range type over +-- domain, custom multi range type over domain. +-- +CREATE DOMAIN int4_d as integer check (value <> 10); +CREATE TYPE int4_d_range as range (subtype = int4_d); +CREATE DOMAIN int4multirange_d as int4multirange check (value <> '{[10,11)}'); +CREATE DOMAIN int4range_d AS int4range CHECK (VALUE <> '[10,11)'); +CREATE DOMAIN textrange2_d AS textrange2 CHECK (VALUE <> '[c,d)'); +CREATE DOMAIN textrange2_dd AS textrange2_d; +CREATE DOMAIN textmultirange2_d AS textmultirange2 CHECK (VALUE <> '{[c,d)}'); This comment still doesn't match the types created below it. In my v4 patch I've added a comment before each CREATE TYPE/DOMAIN line. Also let's define these in the same order that we test them below. +-- It is a range type rather than a domain type; however, the range type’s +-- subtype is a domain type. +CREATE TABLE temporal_rng4 ( + id int4range_d, + valid_at int4_d_range, + CONSTRAINT temporal_rng4_pk PRIMARY KEY(id, valid_at WITHOUT OVERLAPS) +); +INSERT INTO temporal_rng4 VALUES ('[1,2)', '[10,11)'); --error +INSERT INTO temporal_rng4 VALUES ('[10,11)', '[1,2)'); --error +INSERT INTO temporal_rng4 VALUES ('[1,11)', '[9,10)'); --error +INSERT INTO temporal_rng4 VALUES ('[1,2)', '[1,13)'), ('[1,2)', '[2,5)'); --error +DROP TABLE temporal_rng4; We need to test a case that succeeds, not just cases that fail. Also the last case doesn't violate the domain; it just conflicts with a prior row. That's a good test too, but let's clarify. The point is to test WITHOUT OVERLAPS, but several of these lines are testing the id column, not the valid_at column. I made the id columns be just regular int4range. Likewise with the scenarios below. Yours, -- Paul ~{:-) pj@illuminatedcomputing.com -
Re: domain for WITHOUT OVERLAPS
jian he <jian.universality@gmail.com> — 2026-03-10T07:41:49Z
Hi. V4 looks good to me. One minor question regarding comments in transformIndexConstraint: /* * The WITHOUT OVERLAPS part (if any) must be a range or * multirange type. */ Should we change it to: /* * The WITHOUT OVERLAPS part (if any) base type must be a range or * multirange type. */ -- jian https://www.enterprisedb.com/
-
Re: domain for WITHOUT OVERLAPS
Kirill Reshke <reshkekirill@gmail.com> — 2026-03-10T09:53:41Z
On Wed, 11 Feb 2026 at 23:51, Paul A Jungwirth <pj@illuminatedcomputing.com> wrote: > > On Sun, Dec 28, 2025 at 11:18 PM jian he <jian.universality@gmail.com> wrote: > > > > > Is there any performance concern about adding this lookup? > > > From what I can tell we don't use TYPECACHE_DOMAIN_BASE_INFO very > > > often, so it is probably okay. > > > We can get here in the executor from ExecEvalWholeRowVar, but that > > > seems acceptable to me. > > > > > > > > hi. > > > > To make WITHOUT OVERLAPS work with domains, ExecWithoutOverlapsNotEmpty requires > > the base type’s typtype. I do not see a viable alternative approach. > > > > We can cache the base type's typtype in TypeCacheEntry->domainBaseTyptype. > > Okay. > > > > > > > Also testing a range over a domain (in WITHOUT OVERLAPS position) would be good. > > > > > I do not think we need extensive foreign key–related tests, because > > check_exclusion_or_unique_constraint is only invoked for data changes on the > > primary key side. So, I kept only a single foreign key–related test. > > The foreign key code also uses the column type, so there are still > interesting feature combinations here that should be tested rather > than just assuming they work. > > > The attached patch should address all of your comments. > > I think you will like attached regress tests. > > A lot of the issues I mentioned before don't look addressed to me. > What do you think of the v4 patch attached here? It includes a few > more FK tests. Some other details I changed: > > +-- > +-- tests for range over domain, multirange over a domain, custom > range type over > +-- domain, custom multi range type over domain. > +-- > +CREATE DOMAIN int4_d as integer check (value <> 10); > +CREATE TYPE int4_d_range as range (subtype = int4_d); > +CREATE DOMAIN int4multirange_d as int4multirange check (value <> '{[10,11)}'); > +CREATE DOMAIN int4range_d AS int4range CHECK (VALUE <> '[10,11)'); > +CREATE DOMAIN textrange2_d AS textrange2 CHECK (VALUE <> '[c,d)'); > +CREATE DOMAIN textrange2_dd AS textrange2_d; > +CREATE DOMAIN textmultirange2_d AS textmultirange2 CHECK (VALUE <> '{[c,d)}'); > > This comment still doesn't match the types created below it. In my v4 > patch I've added a comment before each CREATE TYPE/DOMAIN line. > > Also let's define these in the same order that we test them below. > > +-- It is a range type rather than a domain type; however, the range type’s > +-- subtype is a domain type. > +CREATE TABLE temporal_rng4 ( > + id int4range_d, > + valid_at int4_d_range, > + CONSTRAINT temporal_rng4_pk PRIMARY KEY(id, valid_at WITHOUT OVERLAPS) > +); > +INSERT INTO temporal_rng4 VALUES ('[1,2)', '[10,11)'); --error > +INSERT INTO temporal_rng4 VALUES ('[10,11)', '[1,2)'); --error > +INSERT INTO temporal_rng4 VALUES ('[1,11)', '[9,10)'); --error > +INSERT INTO temporal_rng4 VALUES ('[1,2)', '[1,13)'), ('[1,2)', > '[2,5)'); --error > +DROP TABLE temporal_rng4; > > We need to test a case that succeeds, not just cases that fail. Also > the last case doesn't violate the domain; it just conflicts with a > prior row. That's a good test too, but let's clarify. > > The point is to test WITHOUT OVERLAPS, but several of these lines are > testing the id column, not the valid_at column. I made the id columns > be just regular int4range. > > Likewise with the scenarios below. > > Yours, > > -- > Paul ~{:-) > pj@illuminatedcomputing.com Hi! I v4, test comments says we check for unique violation, while test output says its exclusion constraint: +INSERT INTO temporal_mltrng4 VALUES ('[1,2)', '{[1,13)}'), ('[1,2)', '{[2,13)}'); -- not unique +ERROR: conflicting key value violates exclusion constraint "temporal_mltrng4_pk" Maybe we can update wording to be more precise? Like `-- overlaps with other tuple`. Other that this nit, patch looks good. -- Best regards, Kirill Reshke -
Re: domain for WITHOUT OVERLAPS
Paul A Jungwirth <pj@illuminatedcomputing.com> — 2026-03-10T16:31:58Z
On Tue, Mar 10, 2026 at 12:42 AM jian he <jian.universality@gmail.com> wrote: > > Hi. > > V4 looks good to me. Thanks for taking a look! > One minor question regarding comments in transformIndexConstraint: > /* > * The WITHOUT OVERLAPS part (if any) must be a range or > * multirange type. > */ > > Should we change it to: > > /* > * The WITHOUT OVERLAPS part (if any) base type must be a range or > * multirange type. > */ Sure. Here is an updated patch. It has some comment adjustments based on Kirill's feedback too. Yours, -- Paul ~{:-) pj@illuminatedcomputing.com -
Re: domain for WITHOUT OVERLAPS
Paul A Jungwirth <pj@illuminatedcomputing.com> — 2026-03-10T16:33:18Z
On Tue, Mar 10, 2026 at 2:53 AM Kirill Reshke <reshkekirill@gmail.com> wrote: > > Hi! > I v4, test comments says we check for unique violation, while test > output says its exclusion constraint: > > +INSERT INTO temporal_mltrng4 VALUES ('[1,2)', '{[1,13)}'), ('[1,2)', > '{[2,13)}'); -- not unique > +ERROR: conflicting key value violates exclusion constraint > "temporal_mltrng4_pk" > > Maybe we can update wording to be more precise? Like `-- overlaps with > other tuple`. > > Other that this nit, patch looks good. Thanks for taking a look! I changed places we say `-- not unique` to now say `-- overlaps`. v5 is attached to my reply to jian he. Yours, -- Paul ~{:-) pj@illuminatedcomputing.com -
Re: domain for WITHOUT OVERLAPS
Tom Lane <tgl@sss.pgh.pa.us> — 2026-04-07T18:57:40Z
Paul A Jungwirth <pj@illuminatedcomputing.com> writes: > Thanks for taking a look! I changed places we say `-- not unique` to > now say `-- overlaps`. v5 is attached to my reply to jian he. I pushed this patch, but not without significant revisions: * I didn't think the case had been made for adding this field to typcache. There's only one user, it's in a very minority-interest code path, and it'd add both space in TypeCacheEntry and a noticeable number of cycles to TYPECACHE_DOMAIN_BASE_INFO requests. (Admittedly the extra-cycles complaint is weak, since we expect TypeCacheEntries to live a long time once populated.) The other problem was that the patch was buggy anyway: there is more than one place in typcache.c that'd have to change. I just moved the get_typtype(typcache->domainBaseType) call to runtime instead. We can revisit that if more potential uses appear. * I thought the number of new regression test cases was quite excessive compared to the value. On my machine, the runtime for without_overlaps.sql went from ~420ms to ~500ms, and it's already the slowest in its parallel group by a good margin. I cut it back to just testing the base domain-over-range and range-over-domain cases, which added only ~5ms. (To be clear, I think it was worth making those tests just to verify there are no other holes. But carrying them forward forevermore is another matter.) * I happened to notice that the loop just above the changes in transformIndexConstraint was buggy: it had "break" where it should have had "continue". That bug can be demonstrated with CREATE TABLE temporal_rng4 ( id int4range, bogus int, valid_at int4 ); ALTER TABLE temporal_rng4 DROP COLUMN bogus; ALTER TABLE temporal_rng4 ADD CONSTRAINT temporal_rng4_pk UNIQUE (id, valid_at WITHOUT OVERLAPS); which gave different errors with and without the DROP COLUMN step. regards, tom lane