Re: [PATCHES] libpq type system 0.9a - Mailing list pgsql-hackers

From Andrew Chernow
Subject Re: [PATCHES] libpq type system 0.9a
Date
Msg-id 47FC3C11.5040800@esilo.com
Whole thread Raw
In response to Re: [PATCHES] libpq type system 0.9a  (Andrew Chernow <ac@esilo.com>)
Responses Re: [PATCHES] libpq type system 0.9a  (Andrew Chernow <ac@esilo.com>)
Re: [PATCHES] libpq type system 0.9a  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> 
> 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);
> }
> 

There is no need to pass hookData to the hook function.  libpqtypes already 
accesses PGconn and PGresult directly so it can just access the hookData member.

int (*connHook)(PGconn *conn, int op);
int (*resultHook)(PGconn *conn, PGresult *result, in top);

-- 
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Concurrent psql API
Next
From: Josh Berkus
Date:
Subject: Re: Calling GSoc Mentors