Re: [BUGS] BUG #14701: pg_dump fails to dump pg_catalog schema

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [BUGS] BUG #14701: pg_dump fails to dump pg_catalog schema
Дата
Msg-id 19748.1497284286@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [BUGS] BUG #14701: pg_dump fails to dump pg_catalog schema  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: [BUGS] BUG #14701: pg_dump fails to dump pg_catalog schema
Re: [BUGS] BUG #14701: pg_dump fails to dump pg_catalog schema
Список pgsql-bugs
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 6/11/17 20:19, Tom Lane wrote:
>> Alternatively, I think that CREATE COLLATION
>> ought to grow the ability to accept "provider = default" and pg_dump
>> should use that.

> We could probably do that at least in pg_dump.  What are the
> expectations for pg_catalog schema dumps?  Are they supposed to be
> restorable?

Hmm, well, actually not --- it certainly wouldn't make any sense to
try to create pg_class again, for instance.  You could imagine changing
the schema name and creating a clone of all the objects, but that
only works for objects with schema-qualified names.  So mostly this
is only useful for documentation, which I think is Neil's use-case
anyway.

That leads to the idea that it would be okay to let pg_dump print
"provider = default" but *not* let CREATE COLLATION accept that.
If we did that and also disallowed cloning the default collation,
then we'd have the property that only the original default collation
has provider 'd', and the existing code would continue to work.
        regards, tom lane


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [BUGS] BUG #14701: pg_dump fails to dump pg_catalog schema
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: [BUGS] BUG #14664: Nonsensical join selectivity estimationdespite n_distinct