| From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
|---|---|
| To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Alex Pilosov <alex(at)pilosoft(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_depend |
| Date: | 2001-07-17 02:58:12 |
| Message-ID: | 3B53A9C4.7FD8EA22@tpf.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Christopher Kings-Lynne wrote:
>
> > Whether the default DROP behavior should be CASCADE, RESTRICT, or the
> > current laissez-faire behavior remains to be debated ;-). The spec
> > is no help since it has no default: DROP *requires* a CASCADE or
> > RESTRICT option in SQL92. But I doubt our users will let us get away
> > with changing the syntax that way. So, once we have the CASCADE and
> > RESTRICT options implemented, we'll need to decide what an unadorned
> > DROP should do. Opinions anyone?
>
> Hmmm...an unadorned drop could remove the object without RESRICTing it or
> CASCADEing it. Hence, if there are objects that depend on it, the object
> will be removed anyway, and dependent objects will not be touched.
We could mark the objects(and their dependent objects) as *INVALID*.
They would revive when reference objects revive in the world of *name*s.
regards,
Hiroshi Inoue
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dominic J. Eidson | 2001-07-17 03:12:26 | Odd error... |
| Previous Message | Hiroshi Inoue | 2001-07-17 02:24:08 | Re: ALTER TABLE ADD COLUMN column SERIAL -- unexpected results |