Re: Order of triggers - totally lost
От | Christoph Haller |
---|---|
Тема | Re: Order of triggers - totally lost |
Дата | |
Msg-id | 3F3A49BE.8BA38DAA@rodos.fzk.de обсуждение исходный текст |
Ответ на | Order of triggers - totally lost ("SZŰCS Gábor" <surrano@mailbox.hu>) |
Список | pgsql-sql |
> The docs say in trigger-datachanges.html: > > "Changes made by query Q are visible by queries that are started after query > Q, no matter whether they are started inside Q (during the execution of Q) > or after Q is done. > > This is true for triggers as well ..." > > Trying to understand that, I have a feeling that the update in A_BIUD should > already see the results of the preceding insert, including the results of > triggers activated by that insert. I've seen that PostgreSQL Weekly News - July 25th 2003 Even though we are nearing release, it doesn't hurt to look ahead, as evidenced by several additions to the TODO list this week: delay resolution of array expression type to assignment coercion can be performed on empty array expressions, have AFTER triggers execute after the appropriate SQL statement in a function, not at the end of the function, more details on possible tablespace definitions were added, add PL/PHP, allow PL/pgSQL to name columns by ordinal position (e.g. rec.(3)), and prevent COMMENT ON DATABASE from using a database name. Some of these already have folks working on them, however if you are interested in lending a hand please don't be afraid to speak up. Looks like this passage about AFTER triggers is what you're expecting, but is not implemented yet. > > What may be wrong? Any ideas to re-organize parts of the triggers? May > putting the update to an A_AU trigger help? I tried it, still have problems > (not sure it's still the trigger order), but the trigger order is still > strange for me: > No ideas, sorry. Maybe move over to the [HACKERS] list for more professional support. Regards, Christoph
В списке pgsql-sql по дате отправления: