Re: pg_migrator issue with contrib

On Mon, Jun 8, 2009 at 1:06 PM, Bruce Momjian<bruce(at)momjian(dot)us> wrote:
> Tom Lane wrote:
>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> > At a minimum it would be great if items could mark themselves as
>> > non-binary-upgradable.
>>
>> It's hardly difficult to make that happen --- just change the C name of
>> some function, or the name of the whole .so file.
>
> Yes, but it needs to happen.  ;-)  PostGIS has done this, which is good.
> The problem is that if they don't do it it is out of the control of
> pg_migrator.

I think it might be possible to implement a system that can't be
broken by accident. Firefox (at least AIUI) requires plugin authors
to explicitly flag their modules as compatible with new versions of
Firefox. When you upgrade your firefox installation in place (heh,
heh) it goes off to the web site and checks whether all of your
extensions have been so flagged. Any that have not been get disabled
automatically.

Obviously we don't want to get into connecting to a web site, but we
could probably come up with some other API for .so files to indicate
which versions of PG they're compatible with. If they don't implement
that API, we assume the predate its introduction and are not
upgradeable. I'm fuzzy on the details here but the point is that if
you implement an opt-in system rather than an opt-out system then
people have to deliberately circumvent it to break things, rather than
just needing to be lazy.

...Robert