Re: Operators on ranges with a domain subtype do not implicitly cast operands of the domain's base type

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Popowich <dpopowich(at)artandlogic(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Operators on ranges with a domain subtype do not implicitly cast operands of the domain's base type
Date: 2022-06-16 20:26:39
Message-ID: 978146.1655411199@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Daniel Popowich <dpopowich(at)artandlogic(dot)com> writes:
> -- domain with underlying type of integer (what constraints we might
> -- place on the integer values are not germane to the issue so they're
> -- left out).
> create domain zzzint integer;

> -- a range on our domain
> create type zzzrange as range (subtype = zzzint);

Why is this a good idea?

ISTM the subtype of a range type shouldn't really be a domain.
The range type depends very fundamentally on the ordering properties
of the subtype, so trying to put some abstraction in there seems a
bit misguided. Moreover, there are a whole bunch of weird semantics
issues that arise if the domain tries to restrict the set of allowed
values. For instance, if the domain disallows "3" (maybe it allows
only even integers) then what does a range (2,10) really mean?
Should we be expected to figure out that it's effectively [4,10)?
What pitfalls does that create for, say, multirange operators?

You could usefully make a domain over the range type and put some
restrictions at that level, perhaps.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bryn Llewellyn 2022-06-16 20:40:56 Re: Operators on ranges with a domain subtype do not implicitly cast operands of the domain's base type
Previous Message Daniel Popowich 2022-06-16 19:59:37 Operators on ranges with a domain subtype do not implicitly cast operands of the domain's base type