Re: domain for WITHOUT OVERLAPS

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/