Florian Pflug <fgp@phlo.org> writes:
> On Feb27, 2014, at 17:56 , Tom Lane <tgl@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
