"David E. Wheeler" <da...@kineticode.com> writes: > The fact that the last two messages in the thread say something else > does not mean that they represent the consensus.
Yeah, but as I'm the one writing the code, I gave myself more than one vote. And did consider the alternatives but didn't like them so much. > Right, I forgot about the relocatable parameter. I kind of expect that most > extensions *would* be relocatable, though. Maybe it should be expected to be > true if it's not present? Or perhaps require non-relocatable extensions to > have a "fixed_schema" control key or something? Either will work, just trying > to find the likely convention to avoid configuration in most cases. Maybe I'm > wrong, though, and most extensions wouldn't be relocatable? Most are, but it's not for granted. See adminpack. Or earthdistance that I had to make not-relocatable for lack of dependency support, as it depends on cube and ALTER EXTENSION earthdistance SET SCHEMA foo would have relocated cube too. We said dependency can wait until v2. I don't see the benefit of having the 'relocatable' property optional in the control file, but I see a huge drawback. Requiring it will force extension authors to at least have a glance at the docs to understand how to set it. It's important not to overlook it. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
