Re: Upgrading Extension, version numbers

"David E. Wheeler" <david@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