Re: Problem with trigger makes Detail record be invalid
| От | Tom Lane |
|---|---|
| Тема | Re: Problem with trigger makes Detail record be invalid |
| Дата | |
| Msg-id | 2795.1524165702@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Problem with trigger makes Detail record be invalid (Fabrízio de Royes Mello <fabrizio@timbira.com.br>) |
| Ответы |
Re: Problem with trigger makes Detail record be invalid
|
| Список | pgsql-general |
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= <fabrizio@timbira.com.br> writes:
> 2018-04-19 15:57 GMT-03:00 Tom Lane <tgl@sss.pgh.pa.us>:
>> (I'm not sure that this issue is adequately documented, though.
>> I'd have expected to find something about it in triggers.sgml and/or
>> create_trigger.sgml, but in a quick look neither of them mentions foreign
>> keys.)
> We don't have it properly documented... at the time I answered this
> question on pt-br stackoverflow I noticed the lack o documentation and
> unfortunately I completely forgot to propose a small patch for it.
It strikes me that there are basically two things a trigger could do to
break FK consistency:
1. Turn an FK-commanded update into a no-op by returning NULL.
2. Change the content of the FK-related columns during an FK-commanded
update.
Both of these apply only to BEFORE ROW triggers, of course.
It might not be unreasonable or unduly expensive to throw an error for
case #1. I don't think I want to get into the expense of checking
for case #2, but covering case #1 would be enough to catch all of the
reports of this type of problem that I can remember.
IIRC, you can also break FK consistency with poorly-thought-out rules,
but given that rules are close-to-deprecated, I'm not very concerned
about sanding down rough edges in that case.
(But if you feel like writing a documentation patch, please do, because
we'd not be likely to back-patch a behavioral change like this even
if we get around to making it.)
regards, tom lane
В списке pgsql-general по дате отправления: