Thread: How to automatically find the *right* libpq_fe.h?

I'm trying to automate an installation of a collection of Perl modules, which requires determining the path to the correct libpq_fe.h file.

On Nov 3, 2009, at 10:09 AM, Kynn Jones wrote:

> I'm trying to automate an installation of a collection of Perl
> modules, which requires determining the path to the correct
> libpq_fe.h file.
>
> My original implementation of the Makefile.PL file for this
> installation set this path as the first valid path that it could
> extract from the output of the system command "locate libpq_fe.h".
>
> Not surprisingly this leads to serious problems when the path so
> "discovered" does not really correspond to the Pg server actually
> running on the machine.
>
> Is there a better way to determine the path to the correct
> libpq_fe.h for a given Pg server, short of asking the user to enter
> it by hand?  (I'm trying to make this installation automatic rather
> than interactive.)
>
> E.g. is there some way to interrogate the running server for this
> information?

There isn't really a "right" libpq-fe.h for a given server, you just
want one that's right for the machine you're installing the app on. As
an extreme case, consider what the answer would be if the database was
on a remote machine.

Rather, use the pg_config you find in the path to get the include
directory (or the compiler flags) or use App::Info::RDBMS::PostgreSQL
or as a last resort $POSTGRES_HOME.

I think DBD::Pg knows all about this already, as well as some fallback
and override techniques, so unless you're doing something non-DBI you
shouldn't have to worry about it.

Cheers,
   Steve

--
GJ

this is somewhat related and very important for the internationalization of postgres db

i  took a look at the localisation routines and could'nt locate any functionality to java getText(int KeyToLookup) ..no big surprise as C preceded Java by at least 10 years

10 years ago i did a contract where I ran thru a mass of legacy code and localised it..the contract was 3 months long and it took every minute to make the localisation work
i'm wondering if there is an faster alternative for legacy apps
here is what i think is the current localisation for deutsche from /po/de.po source distro
#: pl_comp.c:418 pl_handler.c:177
#, c-format
msgid "PL/pgSQL functions cannot accept type %s"
msgstr "PL/pgSQL-Funktionen können Typ %s nicht annehmen"

//In JAVA
//to enable deutsche messages
struts.custom.i18n.resources=globalMessages_de

//globalMessages_de.properties
msgid=Speichern
greeting=GutenTag
item.edit={0} bearbeiten
item.create={0} neu anlegen
item.list={0}-Liste
token.transfer.time=Die \u00dcberweisung wurde am {0,date,HH:mm:ss MM-dd-yyyy} durchgef\u00fchrt
endTag=VielGluck
firstName=Martin

//to acquire localised key for jsp display
    <s:textfield label="%{getText('employee.firstName')}" name="currentEmployee.firstName"/>

?
Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung

> Subject: Re: [GENERAL] How to automatically find the *right* libpq_fe.h?
> From: steve@blighty.com
> Date: Tue, 3 Nov 2009 10:39:10 -0800
> To: pgsql-general@postgresql.org
>
>
> On Nov 3, 2009, at 10:09 AM, Kynn Jones wrote:
>
> > I'm trying to automate an installation of a collection of Perl
> > modules, which requires determining the path to the correct
> > libpq_fe.h file.
> >
> > My original implementation of the Makefile.PL file for this
> > installation set this path as the first valid path that it could
> > extract from the output of the system command "locate libpq_fe.h".
> >
> > Not surprisingly this leads to serious problems when the path so
> > "discovered" does not really correspond to the Pg server actually
> > running on the machine.
> >
> > Is there a better way to determine the path to the correct
> > libpq_fe.h for a given Pg server, short of asking the user to enter
> > it by hand? (I'm trying to make this installation automatic rather
> > than interactive.)
> >
> > E.g. is there some way to interrogate the running server for this
> > information?
>
> There isn't really a "right" libpq-fe.h for a given server, you just
> want one that's right for the machine you're installing the app on. As
> an extreme case, consider what the answer would be if the database was
> on a remote machine.
>
> Rather, use the pg_config you find in the path to get the include
> directory (or the compiler flags) or use App::Info::RDBMS::PostgreSQL
> or as a last resort $POSTGRES_HOME.
>
> I think DBD::Pg knows all about this already, as well as some fallback
> and override techniques, so unless you're doing something non-DBI you
> shouldn't have to worry about it.
>
> Cheers,
> Steve
>
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

---

Bing brings you maps, menus, and reviews organized in one place. Try it now.