Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 8/28/17 15:11, Tom Lane wrote:
>> ... but it seems like you're giving up a lot of the possible uses if
>> you don't make it apply uniformly. I admit I'm not sure how we'd handle
>> the initial creation of a connection object with a custom malloc. The
>> obvious solution of requiring the functions to be specified at PQconnect
>> time seems to require Yet Another PQconnect Variant, which is not very
>> appetizing.
> I would have expected a separate function just to register the callback
> functions, before doing anything else with libpq. Similar to libxml:
> http://xmlsoft.org/xmlmem.html
I really don't much care for libxml's solution, because it implies
global variables, with the attendant thread-safety issues. That's
especially bad if you want a passthrough such as a memory context
pointer, since it's quite likely that different call sites would
need different passthrough values, even assuming that a single set
of callback functions would suffice for an entire application.
That latter assumption isn't so pleasant either. One could expect
that by using such a solution, postgres_fdw could be expected to
break, say, a libpq-based DBI library inside plperl.
regards, tom lane
