Re: RI oddness
От | Tom Lane |
---|---|
Тема | Re: RI oddness |
Дата | |
Msg-id | 16808.988303301@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: RI oddness (Jan Wieck <JanWieck@Yahoo.com>) |
Ответы |
Re: RI oddness
|
Список | pgsql-hackers |
Jan Wieck <JanWieck@Yahoo.com> writes: > What'd be easy is this: > - We already have two entry points for INSERT/UPDATE on FK > table, but the one for UPDATE is fortunately unused. > - We change analyze.c to install the RI_FKey_check_upd > trigger if the constraint has an ON DELETE SET DEFAULT > clause. Otherwise it uses RI_FKey_check_ins as it does > now. Unfortunately, such a fix really isn't going to fly as a patch release. Not only does it not work for existing tables, but it won't work for tables created by dump and reload from a prior version (since they won't have the right set of triggers ... another illustration of why the lack of an abstract representation of the RI constraints was a Bad Move). In fact I'm afraid that your proposed change would actively break tables imported from a prior version; wouldn't RI_FKey_check_ins do the wrong thing if applied as an update trigger? > I think the usage of ON DELETE SET DEFAULT is a very rare > case out in the field. Thus the dump/reload requirement is > limited to a small number of databases (if any). But dump/reload won't fix the tables' triggers. Given that ON DELETE SET DEFAULT isn't used much, I think we should not waste time creating an incomplete hack solution for 7.1.*, but just write it off as a known bug and move forward with a real solution for 7.2. regards, tom lane
В списке pgsql-hackers по дате отправления: