Tom Lane wrote:
> Andrew Chernow <ac@esilo.com> writes:
>> 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.
>
> That's a habit you'd really be best advised to stop, if you're going to
> be a separate library. Otherwise, any time we make an internal change
> in the PGconn struct, it'll break your library --- and we have and will
> feel free to do that without an external soname change.
>
> What parts of PGconn/PGresult do you need to touch that aren't exposed
> already?
>
> regards, tom lane
>
Well, we manually create a result for arrays and composites. We also
use pqResultAlloc in several places. I will have to look at the code
again but I'm not sure we can be completely abstracted from the result
struct.
If you are suggesting that libpqtypes should not access internal libpq,
than this idea won't work. We can pull all the code out and hook in, as
you suggested, but we had no plans of abstracting from internal libpq.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
