Thread: A question about libpgxx

A question about libpgxx

From
"H. Hodzic"
Date:
According to the site hosted at gborg the latest version of libpgxx is 
2.4.2. Is this version compatible with the 8.0-win32 release?

Thanks.




Re: A question about libpgxx

From
Randy Yates
Date:
"H. Hodzic" <hodzicsh@bih.net.ba> writes:

> According to the site hosted at gborg the latest version of libpgxx is
> 2.4.2. Is this version compatible with the 8.0-win32 release?

I am finding it is not. Either that or I'm setting it up incorrectly. 

I've tried to run the test suite by executing "make check" and test001
is bombing with different types of errors - timeout connection errors
and "could not translate xyz.org to address". 

--RY

>
> Thanks.
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq
>

-- 
%  Randy Yates                  % "Bird, on the wing,
%% Fuquay-Varina, NC            %   goes floating by
%%% 919-577-9882                %   but there's a teardrop in his eye..."
%%%% <yates@ieee.org>           % 'One Summer Dream', *Face The Music*, ELO
http://home.earthlink.net/~yatescr



Re: A question about libpgxx

From
jtv@xs4all.nl
Date:
> I am finding it is not. Either that or I'm setting it up incorrectly.

Thankfully I'm pretty sure it's the latter!  Otherwise you'd see test000
failing.  If the problems start at test001 and everything fails after
that, that's a near-certain indicator that the connection to the database
is failing.  Read on below.


> I've tried to run the test suite by executing "make check" and test001
> is bombing with different types of errors - timeout connection errors
> and "could not translate xyz.org to address".

This just means that your connection to the database isn't set up
correctly.  It really doesn't have anything to do with libpqxx; the
underlying C library handles this part, and it needs to know which
database you wish to connect to.  For the self-test the best choice is an
empty throwaway database that the test suite can play with.

As documented in the libpqxx README, you must make sure that there is a
database to connect to, and such that the test programs can log into it
using the default settings.  That typically means your own username and no
password, but you can set the documented environment variables to change
these parameters.

In your case the problem appears to be the definition of the host that the
client library wants to connect to.  On Unix, this would be fixed by
setting the environment variable PGHOST to either the IP address of the
database server, or an absolute filesystem path to a local server's
socket.  The latter is likely to be different under Windows, so you may
have to do some documentation digging there.

Once you get the test running, beware that we've just run into a serious
bug in Visual C++ which causes test failures in large-object support.  So
expect a few test cases to fail if you use any version of Visual C++. 
This is a longstanding and particularly nasty compiler bug that has bitten
us before; the vendor appears to be unwilling to fix it.  A workaround has
just been checked into CVS, so if you need large object support on
Windows, either use a different compiler or wait a few days for the 2.4.3
release.


Jeroen




Re: A question about libpgxx

From
jtv@xs4all.nl
Date:
> I am finding it is not. Either that or I'm setting it up incorrectly.
>
> I've tried to run the test suite by executing "make check" and test001
> is bombing with different types of errors - timeout connection errors
> and "could not translate xyz.org to address".

Here's the documentation on how to specify the parameters of the
connection.  This is from the libpq documentation:

http://www.postgresql.org/docs/7.3/static/libpq-connect.html

> host
>
>    Name of host to connect to. If this begins with a slash, it specifies
Unix-domain communication rather than TCP/IP communication; the value
is the name of the directory in which the socket file is stored. The
default is to connect to a Unix-domain socket in /tmp.
>
> hostaddr
>
>    IP address of host to connect to. This should be in standard
numbers-and-dots form, as used by the BSD functions inet_aton et al.
If a nonzero-length string is specified, TCP/IP communication is
used.

Therefore, using a hostname like xyz.org (is that a preconfigured "please
edit me" default?) with hostaddr is clearly wrong--the option is meant for
numeric IP addresses only, for the specific case that you don't wish to
allow hostname lookups.  Using "host" instead of "hostaddr" (or simply
setting the PGHOST environment variable instead) is going to fix at least
that side of the problem.


Jeroen