Re: BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
| От | Stefan Kaltenbrunner |
|---|---|
| Тема | Re: BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading |
| Дата | |
| Msg-id | 4C1105F9.1060805@kaltenbrunner.cc обсуждение исходный текст |
| Ответ на | Re: BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: BUG #5488: pg_dump does not quote column names ->
pg_restore may fail when upgrading
|
| Список | pgsql-bugs |
Tom Lane wrote: > Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: >> On 10/06/10 16:21, Robert Haas wrote: >>> I do agree that the human readability of pg_dump is an asset in many >>> situations - I have often dumped out the DDL for particular objects >>> just to look at it, for example. However, I emphatically do NOT agree >>> that leaving someone with a 500MB dump file (or, for some people on >>> this list, a whole heck of a lot larger than that) that has to be >>> manually edited to reload is a useful behavior. It's a huge pain in >>> the neck. > >> Much easier to do a schema-only dump, edit that, and dump data separately. > > That gets you out of the huge-file-to-edit problem, but the performance > costs of restoring a separate-data dump are a pretty serious > disadvantage. We really should do something about that. well that is an argument for providing not only --schema-only and --data-only but rather three options one for the table definitions, one for the data and one for all the constraints and indexes. So basically what pg_dump is currently doing anyway but just exposed as flags. Stefan
В списке pgsql-bugs по дате отправления: