=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= <fabrizio@xxxxxxxxxxxxxx> writes: > 2018-04-19 15:57 GMT-03:00 Tom Lane <tgl@xxxxxxxxxxxxx>: >> (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
