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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Daniel Cristian Cruz <danielcristian(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6050: Dump and restore of view after a schema change: can't restore the view
Date: 2011-06-09 23:59:50
Message-ID: 201106092359.p59Nxo216581@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Robert Haas wrote:
> On Tue, Jun 7, 2011 at 11:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Robert Haas <robertmhaas(at)gmail(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Abel Abraham Camarillo Ojeda 2011-06-10 01:58:48 Difference in postgres9.0.4 and postgres9.1beta1 when displaying error lines in functions with comments
Previous Message Robert Haas 2011-06-09 18:22:42 Re: collation problem on 9.1-beta1