Re: [HACKERS] FOREIGN KEY revisited

Поиск
Список
Период
Сортировка
От Thomas G. Lockhart
Тема Re: [HACKERS] FOREIGN KEY revisited
Дата
Msg-id 35E65405.3BEF46B5@alumni.caltech.edu
обсуждение исходный текст
Ответ на FOREIGN KEY revisited  ("Matthew N. Dodd" <winter@jurai.net>)
Ответы Re: [HACKERS] FOREIGN KEY revisited
Список 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 по дате отправления:

Предыдущее
От: "Thomas G. Lockhart"
Дата:
Сообщение: Re: [HACKERS] list macro names
Следующее
От: "Matthew N. Dodd"
Дата:
Сообщение: Re: [HACKERS] FOREIGN KEY revisited