| From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
| Cc: | "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:16:42 |
| Message-ID: | ECEHIKNFIMMECLEBJFIGEEENCBAA.chriskl@familyhealth.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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. It's one
of those things that gives the DBA power, but might let them munge their
database. (Although it's exactly the same as the current way things happen)
Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hiroshi Inoue | 2001-07-17 02:24:08 | Re: ALTER TABLE ADD COLUMN column SERIAL -- unexpected results |
| Previous Message | Tom Lane | 2001-07-17 02:12:14 | Re: Re: SOMAXCONN (was Re: Solaris source code) |