Domains as Subtypes

Background:

Domains lay the groundwork for inherited basetypes
or subtypes. By defining a domain and overriding
operators and possibly creating an operator class, then a domain
can be created which inherits the storage method
and all of the functions of a basetype. The domain
constraint enables a psuedo input function for
the subtype.

Domains enable people to create basetype subtypes using SQL
and procedural languages only. Current belief is that
this "doesn't work." However, all of this has worked
since domains were implemented with three exceptions.

1. PRIMARY KEY uses a type's base type opclass indiscriminantly.
Workaround: for this is to create an opclass for
the subtype and create a UNIQUE index on that column.

2. Operators which take two different types are not found.
The key example for this is a LIKE or ~~ type for a
subtype of text which has as its operands (basetype, parenttype).
Workaround: use the function instead of the operator.

3. ORDER BY uses the parent type's sort operators.
Workaround: Use ORDER BY ... USING 'operator'

Proposal:

This proposal only addresses issue #2. I will look into the
other two as time permits. But there are sensible workarounds
to #1 and #3 in the meanwhile.

This patch passes regression as well as my domain tests.

Attached is a patch to parse_oper.c which essentially does the
following. The major change is in binary_oper_exact().
Instead of checking only one level of the basetype it checks
all possible combinations of type and parent types for
an exact match (only). This favors first the passed in type
and then the basetype for exact matches. The second part of
this change is to lightly loosen the assumption that any operator
has same type operands. If an exact match is not made, the UNKNOWNOID
setting for the original operator is re-instated so that
the function selection mechanism can give it a try.

Tests:

Also attached are two files to create a domain/subtype and
to test it.

Issues/Questions:

1) Code review please.
2) Are there any test cases that were not covered by regression
and my tests?
3) Should I add my test case to the regression tests?
4) Eventually this feature should be added to the docs. Should
I wait until all of the pieces are in place or go ahead and
document the feature as it stands?

elein
--------------------------------------------------------------
elein(at)varlena(dot)com Varlena, LLC www.varlena.com
PostgreSQL Consulting, Support & Training
PostgreSQL General Bits http://www.varlena.com/GeneralBits/
--------------------------------------------------------------
I have always depended on the [QA] of strangers.