Re: Is there a way to 'unrestrict' drop view?

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

In response to

Responses

Browse pgsql-general by date

  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