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 multiple external
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 used to 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 shared object
modules be structured in order to allow code sharing among
functions? (This question is obviously related to the previous
- 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 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?
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.h does not define WARN. Should this be changed to NOTICE in the
Thanks for your help.
pgsql-hackers by date
|Next:||From: Alfred Perlstein||Date: 2000-08-25 14:15:42|
|Subject: vacuuming in the background|
|Previous:||From: Finn Kettner||Date: 2000-08-25 11:58:43|
|Subject: RE: libpq.dll and VB|