Re: New COPY commands in libpq

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

In response to

Browse pgsql-hackers by date

  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?