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 по дате отправления: