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
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 |