Florian Pflug <f...@phlo.org> writes: > On Feb27, 2014, at 17:56 , Tom Lane <t...@sss.pgh.pa.us> wrote: >> That's not a bug, it's a feature, for much the same reasons that pg_dump >> tries to minimize explicit schema-qualification.
> I fail to see the value in this for opclasses. It's certainly nice for > schema qualifications, because dumping one schema and restoring into a > different schema is probably quite common. The value in it is roughly the same as the reason we don't include a version number when dumping CREATE EXTENSION. If you had a default opclass in the source database, you probably want a default opclass in the destination, even if that's not bitwise the same as what you had before. The implication is that you want best practice for the current PG version. Another reason for not doing it is that unique-constraint syntax doesn't even support it. Constraints *have to* use the default opclass. > But how often does anyone dump > a database and restore it into a database with a different default opclass > for some type? Indeed. The root of the problem here is that we've never really thought about changing a type's default opclass before. I don't think that a two-line change in pg_dump fixes all the issues this will bring up. I remind you also that even if you had a 100% bulletproof argument for changing the behavior now, it won't affect what's in existing dump files. The only real wiggle room we have is to change the --binary-upgrade behavior, since we can plausibly insist that people use a current pg_dump while doing an upgrade. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers