Ahh.. Thanks.
I'm completely confident it'll work however when the grammer portions
are added and everything is tracked at creation time. It's been setup
so the calling function must pass the keyword currently, it's a simple
matter of pulling it from the grammer.
However, I'll configure that element (and the domain stuff) to
actually use it -- although they won't cascade very far until the
items they're cascading through also have the ability.
--
Rod Taylor
This message represents the official view of the voices in my head
----- Original Message -----
From: "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
To: "Rod Taylor" <rbt@zort.ca>
Sent: Thursday, March 14, 2002 8:32 PM
Subject: RE: [PATCHES] pg_depend patch
> > To be completed (currently uses old 'ignorance is bliss' methods):
> > - Drop serial on column drop (tables cascade to drop all columns)
> > - Drop triggers via always cascade relationship (uses hard coded
method)
> > - create [ view | trigger | table | sequence | rule | operator |
> > function | aggregate ] need to record dependencies on creation
time.
> > - RESTRICT / CASCADE keywords should be used with drop statements
> > (Always restricts, unless it's an implicit cascade)
>
> If you want something to experiement with, the ALTER TABLE/DROP
CONSTAINT
> code currently REQUIRES the restrict/cascade keyword but just
ignores it...
>
> Chris
>
>