Skip site navigation (1) Skip section navigation (2)

Re: libpq object hooks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "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 16:09:31
Message-ID: 6044.1210867771@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
"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.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2008-05-15 17:40:30
Subject: Re: SSL and USER_CERT_FILE round 2
Previous:From: Tom LaneDate: 2008-05-15 16:01:36
Subject: Re: [rfc,patch] PL/Proxy in core

pgsql-patches by date

Next:From: Bruce MomjianDate: 2008-05-15 16:12:36
Subject: Re: Patch to change psql default banner v6
Previous:From: Alvaro HerreraDate: 2008-05-15 16:09:25
Subject: Re: Patch to change psql default banner v6

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group