From: | Thomas Pasch <thomas(dot)pasch(at)nuclos(dot)de> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Is there a way to 'unrestrict' drop view? |
Date: | 2011-07-22 09:21:26 |
Message-ID: | 4E294116.3030909@nuclos.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
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.
The heart of the my pain is that a program I use works like this. I
would like to migrate the DB beneath it...
Cheers,
Thomas
Am 22.07.2011 10:26, schrieb Willy-Bas Loos:
> On Thu, Jul 21, 2011 at 3:20 PM, Thomas Pasch <thomas(dot)pasch(at)nuclos(dot)de> wrote:
>> I would like to recreate/replace a view, but there are 'dependant
>> objects' on it. Is there a way to 'unrestrict' the dependant check in
>> the current transaction, like it could be done with certain constraints?
>
> Hi,
>
> Nice idea, but i think there isn't a way to do that.
> You will have to drop and re-create the objects in the correct order,
> best in a single transaction.
>
> I can imagine that that can be nasty, even apart from the hassle of
> cutting and pasting + testing that code. You might be needing those
> objects in a running system.
> But then what would it mean to to what you suggest? The dependent
> objects could never function while the view does not exist, so it ends
> up being much the same as drop+create.
> Except that you are changing the view, so you might also need to
> change the depending objects..
>
> Cheers,
>
> WBL
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2011-07-22 09:58:53 | Re: Maximum number of client connection supported by Postgres 8.4.6 |
Previous Message | Ireneusz Pluta | 2011-07-22 08:59:36 | Timestamp parsing with blanked time part |