I have a few questions about what would be expected from coercing to a
type with constraints (Domains mostly -- but complex object types may
run into similar issues if implemented).
What I intend to do:
In gram.y, remove the application of typename directly to the A_Const
in makeTypeCast. Use TypeCast nodes only. This ensures all casts
pass through parce_coerce.c -> coerce_type() which will wrap the
result Node in Constraint Nodes which the executor (ExecQual.c) will
learn how to call ExecEvalConstraint.
ExecEvalConstraint applies NOTNULL and CHECK constraints as is
requested by coerce_type, throwing an error if they don't apply,
similarly to how ExecEvalNullTest returns false if an item doesn't
apply to the null clause.
This should cover forms of:
cast(VALUE as domain) <- makeTypeCast currently avoids this without
the above change
cast(cast(VALUE as othertype) as domain)
select cast(column as domain) from table;
The question I have is about the potential of casting. Should
can_coerce_type evaluate the data involved or not? Currently it
doesn't, and really you have to test every single value before trying
it.
If it's an explicit cast, we do the users bidding and try anyway.
Thats a given. I'm also assuming that implicit coercion tests should
be done against the real type id and not the base type id. So
can_coerce_type and friends won't need to change at all.
Type lengths will be applied the same as cast('fdads' as varchar(3))
would apply the length.
--
Rod
