On Mon, Sep 14, 2009 at 11:20:59PM -0400, Tom Lane wrote:
> There is some moderately interesting reading material in section
> 4.17.4 "Domain constraints" of SQL:2008.
Not sure where to look for a copy of that, nor any particularly helpful
links :(
> In particular, it appears to
> me that the standard goes out of its way to NOT claim that every value
> that "is of" a domain type satisfies the domain's constraints. It looks
> to me that the implementation they have in mind is that domain
> constraints are to be checked:
>
> (1) when a value is assigned to a *table* column having that domain type;
>
> (2) when a value is converted to that domain type by an *explicit*
> cast construct;
>
> (3) nowhere else.
I struggle to get any useful meaning out of the SQL specs, but that
sounds about right to me.
> If I'm reading this right, it sidesteps most of the concerns we have
> been worrying about here, at the cost of being perhaps more surprising
> and less useful than one would expect.
It means that domains are a world away from ADTs (abstract data types)
and just seem to function as quick "templates" for creating new columns.
PG seems to be treating domains as ADTs at the moment, which is the
abstraction that's proved to be more useful in larger programming
projects.
> It would also mean that a lot
> of our existing domain behavior is wrong. I think there is ammunition
> here for an argument that, in effect, values "in flight" in expression
> or query evaluation should always be considered to be of base types,
> and domain constraints should only be checked when assigning to a
> persistent storage location such as a table field or plpgsql variable
> (plus the special case for CAST constructs).
Are you considering changing PGs behavior here? and if so, what would
happen to existing behavior?
-- Sam http://samason.me.uk/
