Re: Re: BUG #6050: Dump and restore of view after a schema change: can't restore the view

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

In response to

Browse pgsql-bugs by date

  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