Re: Referential Integrity problem
От | Stephan Szabo |
---|---|
Тема | Re: Referential Integrity problem |
Дата | |
Msg-id | 20030318182644.U47355-100000@megazone23.bigpanda.com обсуждение исходный текст |
Ответ на | Re: Referential Integrity problem (James Gregory <james@anchor.net.au>) |
Список | pgsql-general |
On 19 Mar 2003, James Gregory wrote: > Ok, so, it seems to me that what I need to do is create trigger > functions to implement this check. They will basically consist of a > check to maintain referential integrity with this inherited structure, > and throw an exception if the proposed modification would break that. > Then, assuming all the checks passed and no exception was thrown it > would simply return the new row. > The script sounds like a bad idea, just from a maintenance standpoint. > So, is there a way to infer what I need to know from within a trigger? > Alternatively, can I specify the table name as a parameter, and use that > to do the system table queries? You can give arguments at CREATE TRIGGER time and do stuff based on the arguments from there. You'll need to be careful to make sure all of the concurrency and modification of the pk side of the constraint works properly. As a note, you'll need triggers on saleable_item and product to deal with modifications to the pk-side of the constraint. The one on saleable_item isn't strictly necessary since you don't plan to modify it, but it's probably good from a consistancy stanpoint. You'll also need triggers on any other saleable_item subclasses.
В списке pgsql-general по дате отправления: