From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org, Daniel Cristian Cruz <danielcristian(at)gmail(dot)com> |
Subject: | Re: Re: BUG #6050: Dump and restore of view after a schema change: can't restore the view |
Date: | 2011-06-07 20:07:51 |
Message-ID: | 19430.1307477271@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Greg Stark <gsstark(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-06-07 21:00:43 | Re: BUG #6041: Unlogged table was created bad in slave node |
Previous Message | Greg Stark | 2011-06-07 20:01:07 | Re: Re: BUG #6050: Dump and restore of view after a schema change: can't restore the view |