"Merlin Moncure" <[EMAIL PROTECTED]> 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 -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches