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