On October 13, 2016 10:12:26 PM PDT, Craig Ringer <cr...@2ndquadrant.com> wrote:
>On 13 October 2016 at 12:37, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Haribabu Kommi <kommi.harib...@gmail.com> writes:
>>> As we are planning to change an extension name from one name to
>>> name because of additional features that are added into this
>> The usual approach to that is just to increase the version number.
>> Why is it necessary to change the name?
>>> I just thought of adding the support of (ALTER EXTENSION name RENAME
>>> newname), this can be executed before executing the pg_upgrade to
>the new
>>> extension name that is available in the
>>> newer version.
>> And if the user forgets to do that before upgrading?  Not to mention
>> that the extension is mostly broken the moment its SQL name no longer
>> corresponds to the on-disk control file name.  This seems like
>> a non-solution.
>> In general, once you've shipped something, changing its name is a
>> pain both for you and your users.  Just say no.
>I've touched on a somewhat related case when I wanted to merge two
>extensions into one. I took a look and quickly punted on it as way too
>messy, but I'm sure there are legitimate use cases for
>splitting/merging extensions. That doesn't mean we want to carry
>little-used infrastructure for it or that anyone's going to care
>enough to implement anything.
>Certainly my need wasn't worth doing it for, and it was a simple one.
>Doing things like extracting only some parts of an extension into
>another extension while maintaining correct dependencies sounds

Hm. Make pgupgrade specify cascade (seems like a good idea anyway) and list the 
new extension as one.  And/or add an automatically installed dependency control 
file field.

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to