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 >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 automatically installed dependency control file field. L Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers