Re: Configurable location for extension .control files - Mailing list pgsql-hackers

From Tom Dunstan
Subject Re: Configurable location for extension .control files
Date
Msg-id CAPPfrux1tUGurvGdUdoQZ=CdFjnUkxSN81fkXsCksD0UR6o2mw@mail.gmail.com
Whole thread Raw
In response to Re: Configurable location for extension .control files  (Dave Page <dpage@pgadmin.org>)
List pgsql-hackers
On 12 June 2013 17:30, Dave Page <dpage@pgadmin.org> wrote:
Messing with the path (or the dynamic load path) can cause all sorts
of fun and interesting problems for users, as we found in the early
days with the EDB installers. I realise it doesn't help these users
(who doubtless don't know it exists) but what we do these days is drop
a "pg_env.sh" file in the installation directory that the user can
source to set their PATH and various PG* environment variables when
they need/want to.

Well, I was imagining something like a helpful dialog box saying "would you like me to fix your path? I'm just going to source /Applications/Postgres.app/env.sh in your bash_profile" and the user can click "ok" or "no thanks I'll do it myself". It might lead to even more confusion, but it's got to be better than the pg gem silently linking against the wrong libpq and subsequently failing in interesting ways.

Of course, if they've already installed the pg gem then it's too late anyway, but at least reinstalling it would then work.

Blech. The more I think about it, the more I like the idea of libpq bundled with the gem.

Cheers

Tom

pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)
Next
From: Brendan Jurd
Date:
Subject: Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)