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
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 |