Thread: Change of extension name to new name
Hi All,
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, so the name is not matching, so we decided
to change the name, but it is causing problem to the already existing installations with old extension
name tries to upgrade to a new version.
9.5 + 'extension_name1' -> 9.6 + 'extension_name2' fails during pg_upgrade when it tries to load
the extension and it's object dependencies on 9.6. If we keep the same extension name then it passed.
Is there any possibility to change the extension name without causing the pg_upgrade failure with minimal changes?
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.
Is there any simpler way to change the extension name, if not any opinion about adding the syntax support to rename an extension?
Regards,
Hari Babu
Fujitsu Australia
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.
regards, tom lane
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. So I'm with you. Just don't rename it. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
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.