From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>, Andrew Chernow <ac(at)esilo(dot)com> |
Subject: | Re: libpq object hooks |
Date: | 2008-05-15 17:48:40 |
Message-ID: | 482C7778.40707@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
> "Merlin Moncure" <mmoncure(at)gmail(dot)com> writes:
>
>> The problem is the functions PQhookData(conn, hookname) and
>> PQresultHookData(result, hookName). We need these to work in
>> functions that are not callbacks. If we eliminate hookname
>> completely, there is no way for libpq to know which private state we
>> are asking for.
>>
>
> Well, depending on a hook name for this is broken-by-design anyway,
> because there is no way for two independently written libraries to
> be sure they don't choose conflicting hook names. So the need for
> a hook name has to go away.
>
> It might work to use the address of the hook callback function as
> a key for retrieving the associated void * pointer. You'd need to
> not register the same callback function more than once per object,
> but from what I gather here you don't need to.
>
>
>
Or else have the library return a unique handle when registering hooks,
rather than supplying a hook name.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Chernow | 2008-05-15 17:50:29 | Re: libpq object hooks |
Previous Message | pgsql | 2008-05-15 17:44:20 | Re: SSL and USER_CERT_FILE |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Chernow | 2008-05-15 17:50:29 | Re: libpq object hooks |
Previous Message | Ron Mayer | 2008-05-15 17:20:53 | Re: Patch to change psql default banner v6 |