2014-02-27 18:15, Florian Pflug <f...@phlo.org>: >> It can be possible to update the new operator class in the new cluster >> as not default, before restore. After the restore, pg_upgrade can upgrade >> the btree_gist extension and reset the operator class as the default. >> pg_upgrade suggests to re-initdb the new cluster if it fails, anyway. Do >> you think it is a better solution? I think it will be more complicated >> to do in pg_dump when in binary upgrade mode. > > Maybe I'm missing something, but isn't the gist of the problem here that > pg_dump won't explicitly state the operator class if it's the default?
No, the problem is pg_upgrade. We can even benefit from this behavior of pg_dump, if we would like to remove the operator classes on btree_gist. Because of that behavior; users, who would upgrade by dump and restore, will upgrade to the better default operator class without noticing. I am not sure not notifying is the best think to do, though. The problem is that pg_dump --binary-upgrade dumps objects in the extension on the old cluster, not just the CREATE EXTENSION statement. pg_upgrade fails to restore them, if the new operator class already exists on the new cluster as the default. It effects all users who use the extension, even if they are not using the inet and cidr operator classes in it. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
