Re: Re: BUG #6050: Dump and restore of view after a schema change: can't restore the view
В списке pgsql-bugs по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Re: BUG #6050: Dump and restore of view after a schema change: can't restore the view |
| Дата | |
| Msg-id | 19430.1307477271@sss.pgh.pa.us обсуждение |
| Ответ на | BUG #6050: Dump and restore of view after a schema change: can't restore the view ("Daniel Cristian Cruz" <danielcristian@gmail.com>) |
| Список | pgsql-bugs |
Greg Stark <gsstark@gmail.com> writes:
> A lot of work has gone into making pg_dump/pg_restore guarantee that
> they'll always produce a copy of the database, even if you've done odd
> things like change the lower bounds of your arrays. A lot of this was
> from before the days of PITR when pg_dump/pg_restore was the *only*
> backup option and it was considered absolutely essential that they
> always work. But even today I think it's still a goal that pg_dump
> always dump a loadable database.
Well, pg_upgrade still depends on pg_dump being a 100% solution for DDL,
so I don't think the requirements have gone down any ...
> I had in mind for pg_dump to decide to use the non-standard syntax iff
> it was necessary at dump time.
Maybe. I'm concerned about the cost of determining whether it's
necessary ("cost" meaning both "runtime" and "code complexity").
regards, tom lane
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера