Re: Domains and subtypes, a brief proposal

On Fri, Sep 08, 2006 at 02:33:13PM -0400, Tom Lane wrote:
> elein <elein(at)varlena(dot)com> writes:
> > Domains and subtypes.
>
> > * Create new child type from values in parent type.
> > * Maintain only checks for constraints
> > * Create implicit casts from child to parent
>
> This seems a bit content-free, because it's not clear how it differs
> from what we do now. We already have implicit child-to-parent casts.

I guess the key point here was to treat the domains as proper udt types
except where constraint checking is required. And yes, this is already
done, but it needed to be included for context.

>
> > Constraints on types:
>
> > * Change the pg_types to hold a NULLABLE constraint text column
> > OR add a type constraint lookup table (pg_domains?)
>
> I understand that you are arguing to allow constraints to be associated
> with any type not only domains, but
> (a) I don't see why we should want to add that overhead, and
> (b) I don't see what that has to do with the problem you actually
> need to solve, specifically limiting the application of implicit
> domain-to-base-type casts.

This is a new feature idea, derived from the implementation of domains.
Usually people store type checking in the input functions, but this is
a nice addition to UDTs that require a constraint checking model.
It allows the constraints to be in plperl which is nice for parsing
complex object stored at strings. (My example was email and the constraint
was a plperl function that validated the format and legitimacy of the value.)

Other complex objects (stored as strings) such as key value lists and
your ordinary weirdly constructed values can use the (more expensive)
constraint at constraint time only instead of the input function which
should remain fast and may be a borrowed or inherited input function.

This is not a drop dead required feature but it should flow from the
cleaner implementation of domains. Changing the check from domain type
to constraint exists on any type should be cleaner. Changing
the SQL for CREATE TYPE should be the added work to get this feature
available.

It just seems simpler and cleaner. We want to treat all types the
same and maintain a type blind database server.

a) if subtypes/domains can have constraints then the model should
not be different for domains only but for all types. Constraint
checking would only
occur at check constraint points--and there for any type. You
already check for the existance of a domain. Change that test
to the existence of a constraint only and eliminate domain specific
code.
b) It is not part of the problem but a logical stretch given the
changes required. It will also reduce the domain checking.

Other than my existing tests (published previously) I do not have a good
idea code wise the extent of the changes. This discussion may help
us get to that point.

>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

elein
elein(at)varlena(dot)com