From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Chernow <ac(at)esilo(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(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 17:08:15 |
Message-ID: | 21866.1207760895@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Andrew Chernow <ac(at)esilo(dot)com> writes:
>>> What parts of PGconn/PGresult do you need to touch that aren't exposed
>>> already?
> Don't need direct access to PGconn at all.
Oh, good, that makes things much easier.
> Also, we basically need write access to every member inside a result
> object ... since we create our own for arrays and composites by copying
> the standard result members over.
Hmm. I guess it wouldn't be completely out of the question to expose
the contents of PGresult as part of libpq's API. We haven't changed it
often, and it's hard to imagine a change that wouldn't be associated
with a major-version change anyhow. We could do some things to make it
a bit more bulletproof too, like change cmdStatus from fixed-size array
to pointer to allocated space so that CMDSTATUS_LEN doesn't become
part of the API.
Alternatively, we could keep it opaque and expose a bunch of manipulator
routines, but that might be a lot more cumbersome than it's worth.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Claudio Rossi | 2008-04-09 17:18:14 | Segfault using heap_form_tuple |
Previous Message | Jeff Davis | 2008-04-09 16:52:49 | Re: [PATCHES] libpq type system 0.9a |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2008-04-09 17:18:54 | Fix for win32 stat() problems |
Previous Message | Jeff Davis | 2008-04-09 16:52:49 | Re: [PATCHES] libpq type system 0.9a |