Re: advice on extensions needed

> - 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?

multiple entry points are fine.

> - 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?

afaik the same file is used.

> - I am writing some functions to handle some new types.  These
>   functions logically should share code.  How should the shared object
>   modules be structured in order to allow code sharing among
>   functions?  (This question is obviously related to the previous
>   two.)

You want *multiple* loadable modules to share code between them? afaik
you will have to make direct calls to the dynamic linker to get this to
happen. Usually, I resolve all symbols within the loadable module since
it is self-contained. However, it may be that the dynamic linker is
smart enough to find symbols from previously-loaded modules; try it out
and then check src/backend/port/dynloader/... for details.

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

Is "extended type" the same as a "user defined type"? Or something else?
If it is a UDT then sure, write away. And if you provide a function with
the target type as the name and taking one argument having the source
type, Postgres will know how to convert it automatically when required.

> - Some of my types will be complex and so it makes sense to have
>   functions extract components of the types (an analogy is what
>   datepart() does).  Should such functions return character strings or
>   some other type?  If they return an appropriate built-in (or
>   extended?) type will the needed conversion be provided
>   automatically depending on context?

Sure, as long as you have the right conversion functions defined and as
long as the conversion can be chosen without ambiguity.

> elog.h does not define WARN.  Should this be changed to NOTICE in the
> docs?

That seems to already be fixed.
                  - Thomas