Robert Haas <robertmh...@gmail.com> writes: > On Thu, Feb 27, 2014 at 12:30 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> 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. Well, I doubt we'd accept a proposal to change the default opclass of a datatype to something that had incompatible behavior --- but we might well accept one to change it to something that had improved behavior, such as more operators. The first couple dozen lines in GetIndexOpClass() make for interesting reading in this context. That approach to cross-version compatibility probably doesn't work in the pg_upgrade universe, of course; but what I'd like to point out here is that those kluges wouldn't have been necessary in the first place if pg_dump had had the suppress-default-opclasses behavior at the time. (No, it didn't always do that; cf commits e5bbf1965 and 1929a90b6.) regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers