On Fri, 20 Jul 2001, Hiroshi Inoue wrote:
> Bill Studenmund wrote:
> >
> > "How does postgres know that the new table a is sufficiently like the old
> > table that it should be used?"
> >
> > By making the reattachment automatic, you are saying that once we make an
> > object of a given name and make objects depend on it, we can never have
> > another object of the same name but different. Because PG is going to try
> > to re-attach the dependants for you.
> >
> > That's different than current behavior, and strikes me as the system being
> > overly helpful (a class of behavior I personally find very annoying).
> >
> > Please understand I like the idea of being ABLE to do this reattachment. I
> > can see a lot of places where it would be VERY useful.
>
> 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 ?
Hmmm... My preference is for the subsequent CREATE to indicate if reattach
should happen or not. But I'm not sure if that would leave dangling depend
entries around.
> 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.
Only partly. I think everyone likes the idea of being able to reattach
later, an idea you came up with. :-)
Take care,
Bill