On Thu, Mar 30, 2006 at 11:51:41AM -0700, Don Y wrote: > - 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"?) You don't have to check. src/backend/utils/mmgr/README > - *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? Maybe a long time ago, but not any longer. > - 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)? They're needed for btree indexes. If you don't want them, you don't need them. > - 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? Create the function and then use CREATE CAST. > - 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. Yes. You specify the size or use a varlena structure. PostgreSQL doesn't try to look inside it. > - 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? Nope, you need to specify, see the CREATE OPERATOR documentation. > - Can *_in() be ever invoked with a NULL argument? Or, can I > safely assume that the pointer I am passed is valid? You can't get a NULL there. Yes, the pointer is valid cstring. > - 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). Can't help you there. Tip: there are various README files scattered around the source tree. Read them. Have a nice day, -- Martijn van Oosterhout <kleptog@xxxxxxxxx> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Attachment:
signature.asc
Description: Digital signature
