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