On 11/10/05, Jeroen T. Vermeulen <[EMAIL PROTECTED]> wrote:
> 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.
No worries, thanks for dealing with it at all.
> 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(); }
No, this didn't work, since the do_startconnect() method is
PQXX_PRIVATE, as well.
> > 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.
I guess, that would work but for now, I rather live with the static
linkage, this way I can use my standard debian packages.
> > 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?
The thing is, I am going to have a lot of those entries, maybe up to
tens of millions, and they are not that "large" after all (a few kB
each). And as far as I know all large objects are stored in one table
(with one index) - so I thought this might be suboptimal. Furthermore,
I am afraid it might be less portable.
> 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. :-/
Thanks, anyway!
Axel
_______________________________________________
Libpqxx-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
