Re: pg_depend

Поиск
Список
Период
Сортировка
От Ross J. Reedstrom
Тема Re: pg_depend
Дата
Msg-id 20010719191336.A32693@rice.edu
обсуждение исходный текст
Ответ на Re: pg_depend  (Hiroshi Inoue <Inoue@tpf.co.jp>)
Список pgsql-hackers
Дерево обсуждения 
On Fri, Jul 20, 2001 at 08:45:05AM +0900, Hiroshi Inoue wrote:
> 
> It doesn't seem preferable that the default(unadorned) DROP
> allows reattachement after the DROP. The default(unadorned) DROP
> should be the same as DROP RESTRICT(or CASCADE because the current
> behabior is halfway CASCADE?). How about adding another keyword 
> to allow reattachment after the DROP ?
> All depende(a?)nt objects must be re-complied after the
> reattachment and the re-compilation would fail if the new table
> isn't sufficiently like the old one.
> 
> Anyway my opinion seems in a minority as usual.
> 

How about making that functionality happen with ALTER <FOO> REPLACE
as Tom suggested? If I'm wanting to change an underlying table, how
likely is it that I don't have the replacement ready right now?

So, instead of:

DROP <FOO> <name> WITH INTENT TO REPLACE

CREATE <FOO> <name> <body>

it's just:

ALTER <FOO> <name> REPLACE <body>

All nice and transactional: if the attempt to reattach one of the 
subordinate objects fails, you roll back to the old one.

Ross

В списке pgsql-hackers по дате отправления: