Re: [BUGS] BUG #14701: pg_dump fails to dump pg_catalog schema
От | Neil Anderson |
---|---|
Тема | Re: [BUGS] BUG #14701: pg_dump fails to dump pg_catalog schema |
Дата | |
Msg-id | CAEKCyStR-GgvqQtHD9_zRghPsbDvGYhjEV+aAbe4xg9wNnfD3w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #14701: pg_dump fails to dump pg_catalog schema (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On 12 June 2017 at 12:18, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. Yes that's what I was using it for. I thought it worth reporting just in case it was a symptom of something bigger. Hopefully it's just for my uncommon case :) > > 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 по дате отправления: