Re: GiST support for inet datatypes

Поиск
Список
Период
Сортировка
От Florian Pflug
Тема Re: GiST support for inet datatypes
Дата
Msg-id 5CD6A309-FC0F-4C52-A0B9-CCEB68AC8948@phlo.org
обсуждение исходный текст
Ответ на Re: GiST support for inet datatypes  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: GiST support for inet datatypes  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Thom Brown
Дата:
Сообщение: Re: Changeset Extraction v7.8
Следующее
От: Tom Lane
Дата:
Сообщение: Re: GiST support for inet datatypes