Re: advice on extensions needed

Brook Milligan <brook(at)biology(dot)nmsu(dot)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