On Thu, Feb 27, 2014 at 12:30 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
I don't think that argument holds a lot of water in this instance. The whole reason for having multiple opclasses that each one can implement different comparison behavior. It's unlikely that you want an upgrade to change the comparison behavior you had before; you'd be sad if, for example, the dump/restore process failed to preserve your existing collation settings. But even if that were desirable in general, suppressing it for binary upgrade dumps certainly seems more than sane. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
