|
1 | 1 | <!-- |
2 | | -$PostgreSQL: pgsql/doc/src/sgml/ref/create_trigger.sgml,v 1.42 2005/11/01 21:09:50 tgl Exp $ |
| 2 | +$PostgreSQL: pgsql/doc/src/sgml/ref/create_trigger.sgml,v 1.43 2005/12/09 19:39:41 momjian Exp $ |
3 | 3 | PostgreSQL documentation |
4 | 4 | --> |
5 | 5 |
|
@@ -241,13 +241,25 @@ CREATE TRIGGER <replaceable class="PARAMETER">name</replaceable> { BEFORE | AFTE |
241 | 241 | function that executes the desired commands. |
242 | 242 | </para> |
243 | 243 | </listitem> |
| 244 | + |
244 | 245 | </itemizedlist> |
245 | 246 | </para> |
246 | 247 |
|
247 | 248 | <para> |
248 | 249 | SQL specifies that multiple triggers should be fired in |
249 | 250 | time-of-creation order. <productname>PostgreSQL</productname> uses |
250 | | - name order, which was judged more convenient to work with. |
| 251 | + name order, which was judged to be more convenient. |
| 252 | + </para> |
| 253 | + |
| 254 | + <para> |
| 255 | + SQL specifies that <literal>BEFORE DELETE</literal> triggers on cascaded |
| 256 | + deletes fire <emphasis>after</> the cascaded <literal>DELETE</> completes. |
| 257 | + The <productname>PostgreSQL</productname> behavior is for <literal>BEFORE |
| 258 | + DELETE</literal> to always fire before the delete action, even a cascading |
| 259 | + one. This is considered more consistent. There is also unpredictable |
| 260 | + behavior when <literal>BEFORE</literal> triggers modify rows that are later |
| 261 | + to be modified by referential actions. This can lead to contraint violations |
| 262 | + or stored data that does not honor the referential constraint. |
251 | 263 | </para> |
252 | 264 |
|
253 | 265 | <para> |
|