Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> 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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
