DOMAIN/composite TYPE vs. base TYPE

[Joe Abbate <jma@xxxxxxxxxxxxxxxxx>]

Hello,

I'm considering creating a TYPE for what may be called a "possibly 
imprecise date" (pidate).  The most obvious use is for recording dates 
such as births or deaths of historical individuals, where we may know 
that someone died precisely on a given year-month-day, but the birth may 
only be known down to year-month or just the year (or perhaps we know 
precisely the baptism date [Adam Smith], but not the actual birth, so we 
want to record the former but qualified so it can be annotated on 
display).  Another use is for publications, like magazines that are 
issued on a monthly basis or journals that are issued on a quarterly or 
seasonal basis.

We currently have two instances of this kind, using a standard DATE 
column plus a CHAR(1) column that encodes (on a limited basis for now) 
the YMD, YM or Y level of precision, and a simple SQL function to return 
a textual representation of the pidate.  It would be nice to generalize 
this before going further.

The first option I explored was creating a composite type with the two 
attributes, but that doesn't allow specification of DEFAULTs, NOT NULL 
or CHECK expressions on the precision code attribute.  It seems I'd have 
to create a DOMAIN first, then use DATE and that domain to create a 
composite TYPE, to finally use the latter in actual tables.  That 
layering looks cumbersome.

Another option, which I havent't tried, is to subvert PG by creating an 
empty table, since that creates a "record type", but even if possible 
that would be a hack.

Finally there's the base TYPE.  This entails writing some seven 
functions "in C or another low-level language" (does PG support *any* 
other such language?), plus installing a library with those functions in 
a production environment.  Doable, yes, but not very friendly either.

Am I overlooking something or is the practice of creating abstractions 
in object-relational databases mostly unchanged?

Regards,

Joe