Re: pg_depend

Bill Studenmund wrote:
>
> On Thu, 19 Jul 2001, Hiroshi Inoue wrote:
>
> > > This step I disagree with. Well, I disagree with the automated aspect
> of
> > > the update. How does postgres know that the new table a is sufficiently
> > > like the old table that it should be used? A way the DBA could say, "yeah,
> > > restablish that," would be fine.
> > >
> >
> > You could DROP a table with CASCADE or RESTRICT keyword if
> > you hate the behavior.
>
> You didn't answer the question. :-)
>
> "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 ?
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.

regards,
Hiroshi Inoue