I'm in the process of extending PostgreSQL and need a bit of advice
that I don't seem to get from the manuals.
- When dynamically linking functions must there be at most one function per shared object module or can there be
multipleexternal entry points within a single shared object?
- If the latter, will multiple copies of the file be loaded (e.g., one per function invoked) or will the same copy be
usedto resolve all the multiple external entry points?
- I am writing some functions to handle some new types. These functions logically should share code. How should the
sharedobject modules be structured in order to allow code sharing among functions? (This question is obviously related
tothe previous two.)
- Is it possible to write functions to automatically convert one extended type into another? If so, how should this be
done?
- Some of my types will be complex and so it makes sense to have functions extract components of the types (an analogy
iswhat datepart() does). Should such functions return character strings or some other type? If they return an
appropriatebuilt-in (or extended?) type will the needed conversion be provided automatically depending on context?
By the way, the new web pages seem to be missing some links. For
example, the "users-lounge/documentation" link just goes to a
directory; shouldn't there be an actual page with links to the various
components of the documentation?
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?
Thanks for your help.
Cheers,
Brook