Peter Eisentraut <peter.eisentr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
