On Mon, November 7, 2005 16:22, Axel Waggershauser wrote:
My apologies for the slow reply: unexpected software upgrade at my
provider clashed with my personal setup, so trouble getting to my email.
Most things should be back to normal now, or even better than what was
normal before.
> I tested it locally with the result, that now the symbol for
> `pqxx::connection::startconnect()' is missing. I found this symbol to
> be referenced from
> .gnu.linkonce.r._ZTV24ConnectionWithExecParams[vtable for
> ConnectionWithExecParams]+0x10. Now this fits pretty good in your
> explenation: The class ConnectionWithExecParams is a custom subclass
> of pqxx::connection I made for the sole purpose of accessing the
> private get_conn() method to use the PQExecParam function to get some
> binary data out of the db without having to escape it (which takes
> ages).
I hadn't really planned for people deriving other classes from the builtin
ones... You should be able to work around this newly missing symbol by
implementing a virtual void ConnectionWithExecParams::startconnect() that
duplicates the missing function body: { do_startconnect(); }
> As far as I understand this with new "feature" of g++-4.0 there is
> nothing we can do about that. With this PQXX_PRIVATE think there is no
> way I am able to subclass pqxx::connection without linking libpqxx
> statically.
Well, I guess you could simply disable use of PQXX_PRIVATE. Just remove
the definition for PQXX_HAVE_GCC_VISIBILITY from
include/pqxx/config-internal-compiler.h and the thing should go away.
Until you run configure again, that is.
> This will all become obsolete if someone can explain to me how to get
> the content of a bytea field without having the server and client to
> escape it.
Use large objects instead of bytea fields perhaps?
I'm not satisfied at all with the way bytea is handled at the moment, but
I don't think we can simply treat bytea as an exception and make it
transfer as binary--after all, the choice of binary vs. textual results
can't be made at column granularity.
What I sort of had in mind for this was to create a result class
hierarchy, with binary and textual implementations. But that would mean
making the functions that actually read fields from the result virtual,
and then the binary implementation of that function would have to switch
on the actual field type, which can't be good for performance except in a
few relatively rare cases. Then there are semantic issues to be
considered: will the exact same type conversions always make sense with a
binary field as with a textual field?
Another possible way to go would be to have a natively-typed result set,
which converts values as they are received, shares values of potentially
large types where they are identical, instead of copying them between
rows, and offers a completely separate, strongly-typed interface that
optimizes out the repeated type checks and so on. But that would take a
lot of work, and it's not like I'm getting paid for this. :-/
Jeroen
_______________________________________________
Libpqxx-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
