Re: Is there a way to 'unrestrict' drop view? - Mailing list pgsql-general

From Thomas Pasch
Subject Re: Is there a way to 'unrestrict' drop view?
Date
Msg-id 4E294116.3030909@nuclos.de
Whole thread Raw
In response to Re: Is there a way to 'unrestrict' drop view?  (Willy-Bas Loos <willybas@gmail.com>)
Responses Re: Is there a way to 'unrestrict' drop view?
Re: Is there a way to 'unrestrict' drop view?
List 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.pasch@nuclos.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

pgsql-general by date:

Previous
From: Ireneusz Pluta
Date:
Subject: Timestamp parsing with blanked time part
Next
From: "Tomas Vondra"
Date:
Subject: Re: Maximum number of client connection supported by Postgres 8.4.6