On Fri, Sep 08, 2006 at 02:33:13PM -0400, Tom Lane wrote: > elein <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match