Re: Configurable location for extension .control files

On 12 June 2013 16:12, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> Yes, they do - including a horde of deeply confused and frustrated Rails
> users struggling to understand why they're getting "no such file or
> directory" or "permission denied" messages about Pg's unix socket,
> because of course they're linked to Apple's libpq which has a different
> default unix socket path, and unless they explicitly specify `host:
> localhost` in their Rails database.yml they get a unix socket connection.
>

Maybe we could ask the rails people to stick a "host: localhost" into their
postgresql examples? Might help a bit, and most users at that level won't
need the absolutely most up-to-date libpq. Of course, there are probably
hundreds of tutorials all over the net that won't have the fix.

> Another option would be to have to explicitly allow use of Apple's
> PostgreSQL (based on known install paths) though; think
> "--use-system-postgresql".
>

Yeah, or --allow-old-libpq or something like that. How will the gem
installer know if the pg_config that it has found is a system one or not?
Going by version number is probably easier.

> I get the strong impression from what I've been reading that a fairly
> typical Rails user setup is:
>
> * Install homebrew
> * Install PostgreSQL using homebrew but don't start it
> * Build the Pg gem against homebrew postgresql's libpq
> * Download and run postgres.app
> * Run your Pg gem using the libpq from homebrew against the postgres.app
> server
>
> Ugh.
>

Hmm. Seems like all the more reason to steer people away from socket-based
comms.

> Good point... though that also raises more concerns regarding consumers
> of the Pg library. And extensions, for that matter; if extensions are
> out-of-tree you need versioned subdirectories, otherwise you'll have
> conflicts between 9.2 and 9.3 (for example) versions of the same
> extensions.
>

Right. I was picturing something like
~/Library/Postgres.app/9.2/extensions. We shouldn't be breaking extensions
within a major release.

> It's also another issue with libpq. User upgrades Postgres.app and
> suddenly their Ruby gems stop working with some linkage error they
> probably don't understand.
>
> (All this is, IMO, really a lesson in why Apple should introduce a
> non-awful packaging system into OS X).

Well, I'm not holding my breath on their packaging changing anytime soon. :)

I wonder if a better approach might be to actually have the gem bundle its
own copy of libpq. Then there's no question of linkage errors when the
server on the system changes, and if users are using tcp rather than unix
sockets, they should be pretty well insulated from those sorts of issues.
Just specify the right port and you're good to go.

Is libpg buildable without building the whole tree? Is it downloadable
without downloading the whole distribution? Hmm.

Cheers

Tom