On Fri, Mar 24, 2006 at 08:33:51PM +0100, Peter Eisentraut wrote:
> elein wrote:
> > Domains lay the groundwork for inherited basetypes
> > or subtypes.
>
> Semantically, a domain and a subtype are completely different things. A
> domain restricts the possible values of a type but behaves exactly like
> that type in all other respects. (The fact that PostgreSQL allows you
> to define functions that take domains as arguments undermines that
> concept but if you apply it carefully it can still work.) Subtypes or
> inherited types on the other hand are defined exactly for the purpose
> of overriding some of their methods (while keeping others unchanged,
> hence the inheritance). Mixing the two concepts might be convenient
> from an implementation point of view but makes no sense in the data
> model.
>
> --
> Peter Eisentraut
> http://developer.postgresql.org/~petere/
>
I have no argument with your point in theory. You make valid arguments.
But in practice, in postgres, we have a strong and orderly type system.
This has been the case since it was designed to have all types be first
class types. Illustra used this to support create type under--mostly for free.
And it was implemented in Informix 9.
It is a fortunate side-effect of this design that domains actually implement
create type under type. When/If we choose to implement subtypes,
everything but the SQL and writing to the catalogs should already work.
In the meanwhile domains work, too.
What I see as the difference between postgresql's implementation of
domains and proper subtypes is the constraint. But I like the constraint.
It makes the subtyping easier to use.
So in theory, you are right. In practice, you can override a domain's
functions and operators and assign it an opclass, making it also
a subtype. (Modulo the three issues I've raised.)
--elein
elein@varlena.com