From: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl> |
---|---|
To: | Tony Reina <reina_ga(at)hotmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: New COPY commands in libpq |
Date: | 2004-05-01 12:34:54 |
Message-ID: | 20040501123454.GD20070@xs4all.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, May 01, 2004 at 02:25:01AM -0700, Tony Reina wrote:
> > You might try porting your code to libpqxx, which is C++-native and should
> > make large swathes of this sort of code unnecessary.
> I've seriously considered it (along with the npgsql library), but am
> not really sure as to what the advantage(s) would be considering that
> (with the corrections suggested) my code works now with libpq.
It depends. It takes a lot of debugging out of your hands because the
boiler-plate stuff like error checking goes into the library, rather than
being rewritten all over the place in the applications. Of course if
your current code works just fine, there's no reason to change anything
so drastic.
> Would there be any improvement in speed with libpqxx? Does libpqxx
> make use of the SSL encryption? How hard is it to link to the SSL
> connections for Postgres commands?
Don't expect any speed improvements per se; libpqxx is a layer on top of
libpq. OTOH some performance features like COPY and limited non-blocking
access (no support for select()ing on multiple file descriptors yet) become
much more easily accessible.
Frankly I don't recall ATM just how libpq deals with SSL. Don't have the
opportunity to look it up just now.
Jeroen
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Payne | 2004-05-01 14:28:25 | Re: [HACKERS] What can we learn from MySQL? |
Previous Message | Fabien COELHO | 2004-05-01 09:29:57 | Re: pg ANY/SOME ambiguity wrt sql standard? |