Re: Domains and subtypes, a brief proposal

On Fri, Sep 08, 2006 at 05:20:18PM -0400, Tom Lane wrote:
> elein <elein(at)varlena(dot)com> writes:
> > I think what you are saying is that the domain checking (proposed constraint
> > existence checking) would need to be done in more places and I'm not sure I
> > understand this.
>
> What I'm complaining about is the need to search the catalogs to see if
> a datatype has constraints. At the moment we need to do that only
> for operations yielding domain types. Your proposal appears to require
> that it be done for *every* operation on *every* datatype, right down
> to int4 and bool (which at the very least creates some interesting
> circularity issues). I'm not willing to accept that much overhead on
> the strength of what is frankly a pretty weak case. If you want a
> constraint, what's wrong with putting a domain on your base type to
> enforce it?
>
> > And checking for constraint <> NULL should be equivalent to the
> > current check *typtype != 'd'.
>
> Not without an amazingly complicated substructure to the "constraint"
> column (multiple entries, names as well as expressions, etc). At the
> very least that's a violation of relational theory, and I'm not sure how
> we're going to handle dependencies of the constraint expressions at all
> if they aren't separate catalog entries.
>
> regards, tom lane

I'm seeing the constraint column as an attribute of the type. It would
at least flag existence of a constraint on a type. This is necessary for
domains as they work now (but we check typtype). This would also be a
catalog change, i.e. non-trivial. It would link types to constraints only
and replace the 'd' value of typtype. Perhaps my ignorance is showing
and I'm missing something. How you have the ability to select the constraint
from the domain name now is fuzzy to me. But I'm trying to move "domains"
from a type of type to just an attribute of type with the goal of simplifying
the behaviour.

The single value result of an expression, on assignment is the only candidate
for constraint checking. Other expression evaluation would behave as is
until assignment to a final result. Theoretically, you would not have to add
constraints other than those defined now. And this should already be working
though the implementation would change slightly with my proposal.

elein
elein(at)varlena(dot)com