Re: Domains as Subtypes

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