Re: extension_control_path - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: extension_control_path
Date
Msg-id 20140114163725.GX2686@tamriel.snowman.net
Whole thread Raw
In response to Re: extension_control_path  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: extension_control_path  (Tom Dunstan <pgsql@tomd.cc>)
List pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> > Please find attached to this email a patch implementing a new GUC that
> > allows users to setup a list of path where PostgreSQL will search for
> > the extension control files at CREATE EXTENSION time.
>
> Why is that a good idea?  It's certainly not going to simplify DBAs'
> lives, more the reverse.  ("This dump won't reload." "Uh, where did
> you get that extension from?" "Ummm...")

We *already* have that problem.  I don't think this makes it
particularly worse- you still need to go back to the old box and look at
what came from where.  Sure, you *might* be lucky enough to find the
right extension by guessing at what packages were installed or searching
for one that looks like the correct one, but then, you might discover
that the version available isn't the right version for the database
you're trying to restore anyway.  Indeed, this might allow folks who
don't particularly care for package systems to build consistent dumps
without having to worry quite as much about what the package system is
doing.

> Assuming that there is some need for loading extensions from nonstandard
> places, would it be better to just allow a filename specification in
> CREATE EXTENSION?  (I don't know the answer, since the use-case isn't
> apparent to me in the first place, but it seems worth asking.)

For my 2c, I could absolutely see it as being worthwhile to have an
independent directory to install not-from-package extensions.  That
would keep things which are "managed by the package system" and things
which are installed independent separate, which is absolutely a good
thing, imv.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Trond Myklebust
Date:
Subject: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Next
From: Florian Pflug
Date:
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)