Re: Configurable location for extension .control files

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

In response to

Browse pgsql-hackers by date

  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)