Re: advice on extensions needed

Brook Milligan <brook@biology.nmsu.edu> writes:
> - When dynamically linking functions must there be at most one
>   function per shared object module or can there be multiple external
>   entry points within a single shared object?

Multi functions per shared object file is fine (in fact normal, I'd
say).  See the example in src/tutorial/.

> - If the latter, will multiple copies of the file be loaded (e.g., one
>   per function invoked) or will the same copy be used to resolve all
>   the multiple external entry points?

Just one copy --- see src/backend/utils/fmgr/dfmgr.c

> - Is it possible to write functions to automatically convert one
>   extended type into another?  If so, how should this be done?

A function named the same as a type, with one argument of some other
type, is treated as an implicit type conversion rule by the parser.

> Also, in the docs for Chapter 5. Extending SQL: Types there is a code
> example with the following:
>     elog(WARN, ...);
> elog.h does not define WARN.  Should this be changed to NOTICE in the
> docs?

elog(ERROR) is the correct equivalent.  Looks like someone fixed that
already; I can't find elog WARN anywhere in the current docs, except for

/home/postgres/pgsql/HISTORY: Change elog(WARN) to elog(ERROR)(Bruce)
        regards, tom lane