Re: domain for WITHOUT OVERLAPS

On Tue, Dec 23, 2025 at 11:25 AM Paul A Jungwirth
<pj(at)illuminatedcomputing(dot)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/