From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Pasch <thomas(dot)pasch(at)nuclos(dot)de> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Is there a way to 'unrestrict' drop view? |
Date: | 2011-07-22 13:56:54 |
Message-ID: | 8808.1311343014@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thomas Pasch <thomas(dot)pasch(at)nuclos(dot)de> writes:
> well, the reason I'm asking is that this *is* posible in Oracle DB. For
> me it looks like that the DB knows that the view is broken. You can't
> use it, *but* it is still there (and it will be usable again when the
> view query is valid again).
> I completely agree that the view should be usable again at the end of
> transaction (even thus Oracle DB doesn't impose that either), but drop
> and re-create the objects in correct order is painful.
Well, if the dependent objects don't need to be touched because the
view's API (its output column set) isn't changing, then you can use
CREATE OR REPLACE VIEW.
If the output column set *is* changing, you need to redefine all the
dependent objects anyway. Oracle may be willing to guess at what
should happen to them, but Postgres isn't.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Albe Laurenz | 2011-07-22 14:19:16 | Re: Is there a way to 'unrestrict' drop view? |
Previous Message | Tom Lane | 2011-07-22 13:52:52 | Re: Timestamp parsing with blanked time part |