From: | Tom Dunstan <pgsql(at)tomd(dot)cc> |
---|---|
To: | Dave Page <dpage(at)pgadmin(dot)org> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Configurable location for extension .control files |
Date: | 2013-06-12 08:41:12 |
Message-ID: | CAPPfrux1tUGurvGdUdoQZ=CdFjnUkxSN81fkXsCksD0UR6o2mw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12 June 2013 17:30, Dave Page <dpage(at)pgadmin(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Brendan Jurd | 2013-06-12 09:05:10 | Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL) |
Previous Message | Dean Rasheed | 2013-06-12 08:22:08 | Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL) |