Re: [PATCHES] libpq type system 0.9a

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/

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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