From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | "Matthew N(dot) Dodd" <winter(at)jurai(dot)net> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] FOREIGN KEY revisited |
Date: | 1998-08-28 06:53:57 |
Message-ID: | 35E65405.3BEF46B5@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> After seeing the work done to implement SERIAL types (automatic
> creation of sequences) would it not be possible to do the same thing
> with FOREIGN KEYs by automatically creating 2 triggers for each
> FOREIGN KEY statement?
It's possible, I suppose, if the code which the triggers execute can be
completely generic (so it is only the equivalent of some "CREATE
TRIGGER" SQL code which must be executed for a new foreign key).
The SERIAL type built on the work I had done to implement PRIMARY KEY
and was pretty trivial to do. However, primary keys are cleaner than the
serial type because the underlying implementation for keys just created
a unique index, which Postgres guarantees to remove if the table is
destroyed. For the serial type, a sequence is created which is _not_
tied directly to the table, and which does _not_ get automatically
destroyed if the table is destroyed.
Hmm, speaking of the serial type, I wonder if I could declare a trigger
to clean up sequences when I destroy a table...
Back to your question: Postgres probably does not remove trigger
functions if a table is destroyed, but that isn't a problem if the
trigger function is generic code which will be reused anyway.
Vadim has been thinking about how to do foreign keys, but I can't
remember if it was via triggers or some other means.
- Tom
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew N. Dodd | 1998-08-28 06:58:08 | Re: [HACKERS] FOREIGN KEY revisited |
Previous Message | Thomas G. Lockhart | 1998-08-28 06:10:35 | Re: [HACKERS] list macro names |