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. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
