Re: GiST support for inet datatypes - Mailing list pgsql-hackers

From Florian Pflug
Subject Re: GiST support for inet datatypes
Date
Msg-id 5CD6A309-FC0F-4C52-A0B9-CCEB68AC8948@phlo.org
Whole thread Raw
In response to Re: GiST support for inet datatypes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: GiST support for inet datatypes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Feb27, 2014, at 17:56 , Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Florian Pflug <fgp@phlo.org> writes:
>> 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?
> 
> 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. But how often does anyone dump
a database and restore it into a database with a different default opclass
for some type?

Or is the idea just to keep the dump as readable as possible?

> At least, it's a feature for ordinary dumps.  I'm not sure whether it
> might be a good idea for binary_upgrade dumps.  That would depend on
> our policy about whether a new opclass has to have a new (and necessarily
> weird) name.  If we try to make the new opclass still have the nicest
> name then it won't help at all for pg_dump to dump the old name.

Well, given the choice between not ever being able to change the default
opclass of a type, and not being able to re-use an old opclass' name,
I'd pick the latter. Especially because for default opclasses, users don't
usually have to know the name anyway.

best regards,
Florian Pflug




pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: Changeset Extraction v7.8
Next
From: Tom Lane
Date:
Subject: Re: GiST support for inet datatypes