"Merlin Moncure" <mmoncure@gmail.com> writes:
> On Fri, May 16, 2008 at 4:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So you're imagining that on creation of a PGconn or PGresult, the
>> hook function would be allowed to create some storage and libpq would
>> then be responsible for tracking that storage? Okay, but that's a
>> separate feature from the sort of passthrough I had in mind. Where
>> exactly does the hook hand off the storage pointer to libpq? What
>> are you going to do if the hook fails to create the storage
>> (ie, out of memory during PGresult creation)?
> Right, this could happen for one of two likely reasons: OOM as you
> suggest or the callback fails for some reason only known to the
> hooking library. In either case, the callback would set the return
> pointer as defined by the structure to null, return FALSE, and libpq
> would not add the state to the array of 'event state datas' it
> maintains.
So at that point we have an apparently-successful creation of a
PGresult, but some of the hook library's functionality is going to fail
to work with that PGresult. That doesn't seem very nice. ISTM the hook
ought to be able to request that libpq return an out-of-memory failure
for the query, just as would happen if the malloc failure had happened
directly to libpq.
regards, tom lane