Re: Is there a way to 'unrestrict' drop view?
От | Thomas Pasch |
---|---|
Тема | Re: Is there a way to 'unrestrict' drop view? |
Дата | |
Msg-id | 4E294116.3030909@nuclos.de обсуждение исходный текст |
Ответ на | Re: Is there a way to 'unrestrict' drop view? (Willy-Bas Loos <willybas@gmail.com>) |
Ответы |
Re: Is there a way to 'unrestrict' drop view?
Re: Is there a way to 'unrestrict' drop view? |
Список | 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 по дате отправления: