From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Adam Tomjack" <adamtj(at)zuerchertech(dot)com>, <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: I incrementally altered my database into a state where backups couldn't be restored. |
Date: | 2007-10-31 13:42:46 |
Message-ID: | 873avrflih.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> That does really suck. But I'm not sure what we can do about it. There's no
>> SQL which is entirely equivalent to the resulting view.
>
> If we were to do anything about it, I think it would have to be to
> forbid the original ALTER. But I don't see any good way to detect
> the situation, either.
Hm, we could call pg_get_viewdef() on dependent views and then verify that the
resulting view compiles without error.
For bonus points we could verify that it produces the same parsed view and
throw warning if it doesn't. That would give us a warning if you have a view
with natural joins which changed meanings.
I'm not sure it's worth that much extra work on every ALTER TABLE though. I
suppose pg_dump() could have an option to check these things itself but by
that point it's too late to do anything about it.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!
From | Date | Subject | |
---|---|---|---|
Next Message | Adam Tomjack | 2007-10-31 16:03:23 | Re: I incrementally altered my database into a state where backups couldn't be restored. |
Previous Message | Tom Lane | 2007-10-31 13:31:12 | Re: I incrementally altered my database into a state where backups couldn't be restored. |