Re: [PATCH] Store Extension Options

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Store Extension Options
Date: 2014-03-13 15:20:02
Message-ID: CA+TgmobN79GGvXKs0aYNbUTNUXgUYxsYXzrgATUQfWLTXz16ng@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 13, 2014 at 10:45 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2014-03-13 10:31:12 -0400, Robert Haas wrote:
>> I think the really interesting question
>> here is how the dump-and-reload issue ought to be handled. As Tom
>> says, it seems on the surface as though you can either require that
>> the provider be loaded for that, or you can accept unvalidated
>> settings. Between those, my vote is for the first, because I think
>> that extensions are not likely to want to have to deal at runtime with
>> the possibility of having arbitrary values where they expect values
>> from a fixed list.
>
>> Basically, my feeling is that if you install an extension that adds
>> new table-level options, that's effectively a new version of the
>> database, and expecting a dump from that version to restore into a
>> vanilla database is about as reasonable as expecting 9.4 dumps to
>> restore flawlessly on 8.4.
>
> Pft. I don't expect a restore to succeed without the library present,
> but I think any such infrastructure should work with a CREATE EXTENSION
> installing the provider. Especially if we're trying to make this into
> something more generic than just for pure security labels. It might make
> sense to always require the library be always loaded for selinux or
> whatnot, but much less so if it's for a schema management tool or
> something. Relying on shared_preload_library seems to run counter the
> route pg's extensibility has taken.

Well, I don't have a big problem with the idea that some sessions
might not have a certain extension loaded. For some extensions, that
might not lead to very coherent behavior, but I guess it's the
extension developer's job to tell the user whether or not that
extension needs shared_preload_libraries, needs either shared or local
preload_libraries, or can be installed however. At the same time, I
don't feel compelled to provide an autoload mechanism to cover the
case where a user tries to set a label in a session which does not
have the label provider preloaded. Such a mechanism will be complex
and introduce many problems of its own for what is in my mind a pretty
darn narrow benefit; and we sure as heck do not have time to engineer
it for 9.4.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2014-03-13 15:22:58 Re: jsonb and nested hstore
Previous Message Robert Haas 2014-03-13 15:15:56 Re: [PATCH] Store Extension Options