Re: libpq object hooks

"Merlin Moncure" <mmoncure(at)gmail(dot)com> writes:
> Right. I actually overlooked the 'passthrough' in
> PQregisterEventProc. It turns out that we are still not quite on the
> same page and this needs to be clarified before we move on. The
> passthrough cannot exist...

Yes, it *will* exist. You are assuming that the goals you have for
these hooks are the only ones anyone will ever have. There are other
possible usage patterns and many of them will need some passthrough
state data. I'd venture to say that anytime I've ever used a callback
design that did not include a passthrough, I've had reason to curse
its designer sooner or later (qsort being a pretty typical example).

However, it's clear that we are not on the same page, because what
I thought you wanted the PQeventData function to return was the
passthrough pointer. Evidently that's not what you want it to do,
so you'd better back up a few steps and say what you do want it to do.
(I think that a function to get the passthrough value associated with
a given hook function might be useful too, but it's clear that what
you are after must be something else.)

> The purpose of the callbacks is to allow a hooking library to
> establish private data that is associated with a PGconn or a PGresult.

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)?

> Invoking PQregisterEventProc tells libpq 'I am interested in doing
> this', for the supplied PGconn, future results created with that
> connection, and (if PGconn is passed as null), all future connections.

I am entirely serious about saying that I will not accept that last bit.
To do that we have to buy into having permanent modifiable storage
within libpq, protecting it with thread mutexes, etc etc. And I don't
like any of the possible usage scenarios for it. I think hooking into a
PGconn immediately after its creation is just as useful and a lot easier
to manage.

> Once that is established, libpq begins telling the hooking library
> when and what needs to be allocated or deleted.

Wait a minute --- you're trying to get between libpq and malloc?
Why? That's getting a *whole* lot more invasive than I thought
this patch intended to be, and I don't see a good reason for it.

regards, tom lane