| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Groff, Dana" <Dana(dot)Groff(at)filetek(dot)com> |
| Cc: | "'pgsql-hackers(at)postgreSQL(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Should this require CASCADE? |
| Date: | 2002-07-11 03:09:02 |
| Message-ID: | 8969.1026356942@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Groff, Dana" <Dana(dot)Groff(at)filetek(dot)com> writes:
> Actually, the answer is even clearer, the standard calls for the specification
> of "CASCADE" or "RESTRICT" and doesn't support _not_ having that specified.
> (the <drop behavior> is NOT [drop behavior] aka optional)
Right, the spec does not allow it to be defaulted. We will, however,
since the alternative is breaking every PG application that uses DROP.
Defaulting to RESTRICT behavior seems a reasonably safe way of
preserving as much backwards compatibility as we can.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bradley Baetz | 2002-07-11 03:15:13 | Re: [INTERFACES] [pgaccess-users] RE: bugzilla.pgaccess.org |
| Previous Message | Bradley Baetz | 2002-07-11 03:08:11 | Re: [INTERFACES] [pgaccess-users] RE: bugzilla.pgaccess.org |