On Thu, Mar 13, 2014 at 10:45 AM, Andres Freund <and...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
