Re: Upgrading Extension, version numbers - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: Upgrading Extension, version numbers
Date
Msg-id E4E469B5-90AC-4285-B93F-A41CF50D1EF7@kineticode.com
Whole thread Raw
In response to Re: Upgrading Extension, version numbers  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Upgrading Extension, version numbers  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
On Jan 3, 2011, at 11:46 AM, Dimitri Fontaine wrote:

> Not what I have understood.
>
>  http://archives.postgresql.org/pgsql-hackers/2010-12/msg01014.php
>  http://archives.postgresql.org/pgsql-hackers/2010-12/msg01045.php
>
> AS there was no answer, the meaning for me is that it was ok to
> proceed.  On this list people agreeing often remain silent.

There were several of us who were not silent.
 http://archives.postgresql.org/pgsql-hackers/2010-12/msg00804.php
http://archives.postgresql.org/pgsql-hackers/2010-12/msg00796.php

The fact that the last two messages in the thread say something else does not mean that they represent the consensus.

>>> Note that we always need to support the placeholder here, because of
>>> course following dependencies at this point isn't possible.
>>
>> I thought placeholders were going away, too. Did I lose track?
>
> Oh, dear, yes :)  See the documentation for the relocatable parameter.
> We know handle two kinds of extensions, some of them you can't offer
> better than placeholders to allow users to define the schema where they
> will land.  Also, at upgrade time, I don't see any other way to solve
> the problem.  Do you?
>
>  http://pgsql.tapoueh.org/extensions/doc/html/extend-extension.html

Right, I forgot about the relocatable parameter. I kind of expect that most extensions *would* be relocatable, though.
Maybeit 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
configurationin most cases. Maybe I'm wrong, though, and most extensions wouldn't be relocatable? 

> Yeah.  Before extension existed, it has always been working like that,
> our users already depend on such a behavior, nothing new here.  I just
> don't see how extension could solve that is all I'm saying.

Fair enough.

>> The new .so should not be installed until the upgrade is been run.
>
> Nice statement.  How do you make that happen?

Nope.

David



pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: Extension upgrade, patch v0: debug help needed
Next
From: Dave Page
Date:
Subject: Re: back branches vs. VS 2008