Re: BUG #6050: Dump and restore of view after a schema change: can't restore the view - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: BUG #6050: Dump and restore of view after a schema change: can't restore the view
Date
Msg-id 201106092359.p59Nxo216581@momjian.us
Whole thread Raw
In response to Re: BUG #6050: Dump and restore of view after a schema change: can't restore the view  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-bugs
Robert Haas wrote:
> On Tue, Jun 7, 2011 at 11:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Robert Haas <robertmhaas@gmail.com> writes:
> >> If your point here is that you don't want to spend time hacking on
> >> this because it's a fairly marginal feature and therefore not terribly
> >> high on your priority list, I can understand that. ?But if you're
> >> actually defending the current implementation, I'm going to have to
> >> respectfully disagree. ?It's broken, and it sucks, and this is not the
> >> first complaint we've had about it.
> >
> > The spec's definition of USING is broken and sucky, and we're
> > implementing it as best we can. ?I don't feel a need to invent
> > strange nonstandard behavior to work around the fact that USING
> > is fragile *by definition*. ?Complain to the standards committee
> > about that.
>
> It's not the standard's committee's fault that our dump won't restore.
>  They may not have made life any easier for us, but if we're going to
> have the feature, then pg_dump ought to work.  Otherwise, we're
> telling people "you can use this feature, but don't expect to be able
> to restore from backup".  Not a way to win friends.
>
> > (Question: would you also have us try to work around the fact that
> > USING stops working if you rename one of the join columns?)
>
> Yeah.  In fact, I proposed a patch to do just that in response to bug
> #5234, which you shot down.  I still don't agree with that.  We can
> either disallow the original DDL (adding or renaming a column in a way
> that causes the dumped representation to become invalid) or we can
> change what we dump so that it can be reloaded.  Letting the user
> change the view definition and then producing an unrestorable dump
> seems truly awful to me, regardless of how little help we're getting
> from the SQL standards committee.

Reminder, pg_upgrade is also going to be unusuable if pg_dump generates
an error, even on a view.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

pgsql-bugs by date:

Previous
From: Robert Haas
Date:
Subject: Re: collation problem on 9.1-beta1
Next
From: Abel Abraham Camarillo Ojeda
Date:
Subject: Fwd: Difference in postgres9.0.4 and postgres9.1beta1 when displaying error lines in functions with comments