Re: [HACKERS] FOREIGN KEY revisited - Mailing list pgsql-hackers

From Thomas G. Lockhart
Subject Re: [HACKERS] FOREIGN KEY revisited
Date
Msg-id 35E65405.3BEF46B5@alumni.caltech.edu
Whole thread Raw
In response to FOREIGN KEY revisited  ("Matthew N. Dodd" <winter@jurai.net>)
Responses Re: [HACKERS] FOREIGN KEY revisited  ("Matthew N. Dodd" <winter@jurai.net>)
List 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

pgsql-hackers by date:

Previous
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] list macro names
Next
From: "Matthew N. Dodd"
Date:
Subject: Re: [HACKERS] FOREIGN KEY revisited