User defined data type - Mailing list pgsql-general

Hi,

I'll hope this is the correct list for these questions... :-/

I need to define several unique data types.  As my "make one
to throw away" exercise, I rewrote the ISBN data type in
the contrib directory (hopefully bringing it "up to date"
as well as adding stricter checks in the parser and shrinking
the INTERNALSIZE of the type).

It seems to work well -- though I have yet to beat on it
with a brass hammer.  :-/

I've tried perusing the documentation looking for a boilerplate
approach to this but haven't yet found one (I'm running 8.0.3).
I notice the 8.2devel docmentation seems to fill in some of the
missing holes (though still not in a straightforward "do this"
template  :-/  )

So, a couple of questions:

- I assume I don't have to check the return value from
   palloc()?  (All of the src/backend/utils datatypes
   seem to trust it implicitly)  BTW, where is the interface
   to palloc() et al. documented (or, is it a case of "Use
   the Source, Luke"?)
- *Somewhere*, I saw a reference claiming functions (and
   the sources thereof?) had to fit in an 8KB "page" (?)
   as they are stored in the database.  But, empirical
   observation seems to refute that (perhaps it was true
   in an older release?)  Are there any such limits?
- Aside from the in and out functions, all I've defined
   for *this* data type are the <, <=, =, >=, >, <> operators
   and a comparison function.  It is my understanding that
   these are needed to support keys/indexes on that data type.
   Is this true?  I.e. if can I discard some of these if I
   am willing to live without keys, etc.?  Are there other
   things that I need to add (or should consider adding)?
- How do I create functions to perform typecasts?  For
   example, *assume* an int4 could be cast to an "isbn"...
   where would that function be implemented?
- This data type contains some redundant information not
   needed for the various operators mentioned above.  Does
   that get in the way of anything?  I.e. it is my understanding
   that the in and out routines are *all* that is needed to
   preserve/transport that "redundant" information to a new
   table/database/etc.
- If not explicitly listed, does the server *assume* things
   like NEGATOR of <= is >?  Or, COMMUTATOR of <= is >=?  Or,
   are these attributes simply "not present" unless explicitly
   defined?
- Can *_in() be ever invoked with a NULL argument?  Or, can I
   safely assume that the pointer I am passed is valid?
- Wish list item:  errdetail(va_list arg) et al. functions (Yeah,
   I can write my own... but it would be nice if this was part
   of the error reporting routines).

If necessary, I could post the source and .sql files but
they may waste a fair bit of bandwidth (about 20KB) -- mainly
due to embedded commentary, etc.

Thanks for any pointers.  And, apologies if this was the
*wrong* list for this post!  :-(

--don