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