Re: Automatic detection of PostgreSQL version

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Roberto Costa <rob(dot)costa(at)libero(dot)it>
Cc: PostgreSQL interfaces mailing list <pgsql-interfaces(at)postgresql(dot)org>
Subject: Re: Automatic detection of PostgreSQL version
Date: 2003-03-12 00:35:11
Message-ID: Pine.LNX.4.44.0303120121460.1617-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

Roberto Costa writes:

> What I'm currently doing is searching typical include directories (like
> /usr/include, /usr/local/share/include, ...) for the presence of a
> directory named postgresql or pgsql that contains config.h or
> pg_config.h (used since PostgreSQL 7.2, if I'm not wrong). When such a
> file is found, I grep it for a line that starts with "#define
> PG_VERSION" and I expect the version follow and be in the form "x.y.z".
> This works for the latest PostgreSQL versions that I could test,
> however I don't know whether this check may work with earlier ones. In
> reality I even ignore if this kind of check is the best way to get what
> I want.

All of that seems highly unusual. configure scripts are supposed to check
for alternative features in libraries, not search the entire file system
for the "best" library. I suggest you just include the libpq++ header
file in your code and be done with it. If it's missing the user will get
an error from the compiler and will know what to do. (Possibly there will
be some documentation to help him, too.) Users that have multiple
versions installed can select the one to use with the usual CPPFLAGS and
LDFLAGS variables.

--
Peter Eisentraut peter_e(at)gmx(dot)net

In response to

Responses

Browse pgsql-interfaces by date

  From Date Subject
Next Message Peter Eisentraut 2003-03-12 00:35:18 Re: Postgres Scaling
Previous Message Peter Eisentraut 2003-03-12 00:34:55 Re: permanently setting PROMPT1