Emre Hasegeli <e...@hasegeli.com> writes: > 2014-02-17 14:54, Andres Freund <and...@2ndquadrant.com>: >> You need to add a file for going from 1.0 to 1.1.
> Thank you for the notice. I added them to the patches which touch only two > of the operator classes. It drops and re-creates operator classes as there > is not ALTER OPERATOR CLASS DROP DEFAULT command. Dropping an operator class is quite unacceptable, as it will cause indexes based on that class to go away (or more likely, cause the upgrade to fail, if you didn't use CASCADE). What we've done in the past for changes that are nominally unsupported is to make the upgrade scripts tweak the system catalogs directly. More generally, it doesn't look to me like these upgrade scripts are complete; shouldn't they be creating some new objects, not just replacing old ones? We need to have a discussion as to whether it's actually sane for an upgrade to remove the DEFAULT marking on a pre-existing opclass. It strikes me that this would for instance break pg_dump dumps, in the sense that the reloaded index would probably now have a different opclass than before (since pg_dump would see no need to have put an explicit opclass name into CREATE INDEX if it was the default in the old database). Even if the new improved opclass is in all ways better, that would be catastrophic for pg_upgrade I suspect. Unless the new opclass is on-disk-compatible with the old; in which case we shouldn't be creating a new opclass at all, but just modifying the definition of the old one. In short we probably need to think a bit harder about what this patch is proposing to do. It seems fairly likely to me that some other approach would be a better idea. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers