Re: User defined data type

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@svana.org>   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.