On October 13, 2016 10:12:26 PM PDT, Craig Ringer <craig@2ndquadrant.com> wrote:
>On 13 October 2016 at 12:37, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Haribabu Kommi <kommi.haribabu@gmail.com> writes:
>>> As we are planning to change an extension name from one name to
>another
>>> name because of additional features that are added into this
>extension,
>>
>> 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
>To
>>> 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
>huge
>> 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
>nightmarish.
Hm. Make pgupgrade specify cascade (seems like a good idea anyway) and list the new extension as one. And/or add an
automaticallyinstalled dependency control file field.
L
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
