Re: [HACKERS] FOREIGN KEY revisited

> 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