User defined data type

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