On Fri, Sep 08, 2006 at 03:47:23PM -0400, Tom Lane wrote:
> elein <elein@varlena.com> writes:
> > 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.
>
> Au contraire, the test whether a constraint actually exists occurs at
> runtime, not at the time we check for domain-ness. Your proposal would
> force such checks to be introduced into every single expression
> evaluation. It's not feasible at all without plan invalidation, and
> even with that I foresee fairly enormous added overhead. Our experience
> with domains so far is that looking up those constraints is *expensive*.
For domain checking isn't expression evaluation required anyway?
email := email_value || email_value should fail on a constraint check for
result value at assignment time.
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.
I believe constraints checking should done less often than input
types. And checking for constraint <> NULL should be equivalent to the
current check *typtype != 'd'. I could be wrong base on the current
implementation. There may be more to it, but I suspect making sure the
constraint value is available when you fetch a type would be necessary.
Turn the thing around a bit. The contraint is an attribute on anytype.
All type code, only where appropriate, should check for existence of
the constraint attribute. This is different from saying domains as
special types and need special casing in places (other than constraint checking).
I'm trying to remove the specialness from domains so that the type
code can pretty well work as is in all places execpt checking for the
constraint attribute of a type. This should solve some of the existing
domain problems.
We're pretty close to this as is, but there is still a lot of special
casing going on. The ability to add constraints to any type should
only be considered as a logical extension made easier by the change
in what you test when you test for constraints.
elein
elein@varlena.com