Re: pg_depend patch

From: "Rod Taylor" <rbt(at)zort(dot)ca>
To: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
Cc: <pgsql-patches(at)postgresql(dot)org>
Subject: Re: pg_depend patch
Date: 2002-03-15 12:20:38
Message-ID: 01ce01c1cc1b$d1996980$8001a8c0@jester
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

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(at)familyhealth(dot)com(dot)au>
To: "Rod Taylor" <rbt(at)zort(dot)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
>
>

Browse pgsql-patches by date

  From Date Subject
Next Message Rod Taylor 2002-03-15 12:20:41 Re: pg_depend patch
Previous Message Bruce Momjian 2002-03-15 05:32:23 Re: JDBC arrays