* Dimitri Fontaine (dimitri@2ndQuadrant.fr) wrote:
> Who do you think should have a say about where to load the dynamic
> librairies from? hackers, packagers, system admins, dbas or users?
My gut feeling on this is packages and sysadmins. Do you see it
differently? I generally *don't* think DBAs-who-aren't-sysadmins should
be doing it as they may not have any access to the underlying OS (or
perhaps have access only to things like /home), which goes back to my
concerns over ALTER SYSTEM, but that ship has obviously sailed.
> Who do you think is currently editing the setup that decides where to
> load the dynamic librairies from, which is spread into SQL scripts,
> extension control file, postgresql.conf and pg_config --pkglibdir?
I agree that packagers and sysadmins will be setting this up initially,
but it strikes me as a bit silly to ask the sysadmins to go modify the
control file path and then also have to modify the dynamic library load
path when they're setting them to the same thing.
Related to this, as I've asked repeatedly on this thread- what is the
plan for dealing with namespace overlaps? As in, the admin happily goes
in and sets dynamic_library_path to '$libdir:/path/to/new/hstore' and
then tries to CREATE EXTENSION hstore; with the -contrib packages
installed? They're going to get cryptic and bizarre error messages, at
best during the CREATE EXTENSION and at worst when they actually try to
run that one function whose interface changed, perhaps months after the
initial install.
Part of the reason that I'm pushing for a change here is to try and
address that problem. I'd appreciate some feedback on it.
> What exactly are you calling bizarre in the idea that the PostgreSQL
> source code is maybe not the best way where to solve that problem from?
I was referring to the apparent role reversal between us, with me trying
to get PG to do more and you pushing to have more in an external tool.
It wasn't that long ago that our positions were swapped.
Thanks,
Stephen
