Andrew Dunstan wrote:
I don't get what you're not seeing about this.
All I am trying to say is, redhat's core packages are normally very
inclusive. Like apache, which includes many/most modules in the core
package.
I am still not convinced there is merit to a separate library. But
honestly, I'm indifferent at this point. If the community wants it this
way, whether or not I agree with the reasons, then consider it done.
It would be helpful to get some feedback about what the requirements are
for a hooking mechanism for libpqtypes:
1. Do we make the hooking system generic, for other library to use?
2. If #1 is YES, then does this hooking system need to allow registering
multiple hooks per app instance. Meaning, should we implement a table
of callbacks/hooks? Like a linked list of them.
3. What design is preferred?
*) A single msg proc that uses a msg object which is either a big union
or something that gets up casted.
*) A separate function pointer per hook, like conn_create, conn_destroy
*) A combo, where conn hooks are handled by one funcptr and result hooks
by another. But each only has one function.
Please think carefully about question #1, as this could lead to
over-design or guess-design.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
