From: | Andrew Chernow <ac(at)esilo(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCHES] libpq type system 0.9a |
Date: | 2008-04-09 03:38:14 |
Message-ID: | 47FC3A26.5070301@esilo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Andrew Chernow wrote:
>
> Any thoughts on the hooking suggested by Tom? It sounds like it should
> be generic enough so more than just libpqtypes can make use of it. I
> think something of this nature should have input before I do anything.
>
> Possible Hook points: (at least ones needed by libpqtypes)
> conn_create
> conn_reset
> conn_destroy
> result_create
> result_destroy
>
> I guess libpqtypes would have to maintain a map of conns and results?
> Right now it can associate type info because we added members to conn
> and result. When conn_create(conn) is called, libpqtypes would need to
> map this by pointer address (as it is all it has as an identifier).
> Still feels like maybe there should be a void* in a conn and result used
> for per-connection/result based info (libpqtypes or not).
>
Well, I can get it working with a very small patch. We actually don't need very
much in libpq. Although, making it somehow generic enough to be useful to other
extensions is a bit tricky. Please, suggestions would be helpful.
Below is a raw shell of an idea that will work for libpqtypes. Start by
removing our entire patch and then add the below:
// libpqtypes only needs the below. could add op_reset,
// op_linkerror, etc...
enum
{
HOOK_OP_CREATE,
HOOK_OP_DESTROY
};
struct pg_conn
{
// everything currently in a pg_conn
// ...
// libpqtypes needs HOOK_OP_DESTROY, a ptr to hookData
// is always used in case the hooklib needs to allocate
// or reallocate the hookData.
void *hookData;
int (*connHook)(PGconn *conn, int op, void **hookData);
}
struct pg_result
{
// everything currently in a pg_result
.....
// libpqtypes needs create & destroy
// conn is NULL for destroy
void *hookData;
int (*resultHook)(PGconn *conn, PGresult *result,
int op, void **hookData);
}
freePGconn(PGconn *conn)
{
// ...
if(conn->connHook)
conn->connHook(conn, HOOK_OP_DESTROY, &conn->hookdata);
// ...
}
PQmakeEmptyPGresult(PGconn *conn, ExecStatusType status)
{
// ... (result allocated here)
if(result->resultHook)
result->resultHook(conn, result,
HOOK_OP_CREATE, &result->hookData);
// ...
}
PQclear(PGresult *result)
{
// ...
if(result->resultHook)
result->resultHook(NULL, result,
HOOK_OP_DESTROY, &result->hookdata);
// ...
}
// library wide
int PQregisterHooks(connHook, resultHook);
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-04-09 03:42:12 | Re: Concurrent psql API |
Previous Message | Tom Lane | 2008-04-09 03:37:32 | Re: Concurrent psql API |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-04-09 03:42:12 | Re: Concurrent psql API |
Previous Message | Tom Lane | 2008-04-09 03:37:32 | Re: Concurrent psql API |