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
