Re: Event Triggers: adding information

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Nice clean patch, thanks!
>
> Committed, after tinkering with the CommandCounterIncrement() stuff a bit.

Cool. thanks!

> I will respond to the rest of your email later. Reading through this
> patch left me with a slight concern regarding both ddl_command_start
> and ddl_command_end: what happens if there's more than one event
> trigger scheduled to fire, and one of them does something like drop
> (with cascade) the function that a later one uses? Admittedly, that
> seems like an unlikely case, but we probably want to check that
> nothing too awful happens (e.g. crashing the server) and maybe add a
> regression test to cover this scenario.

I added some in the attached patch.

doc/src/sgml/event-trigger.sgml | 10 ++
src/backend/commands/event_trigger.c | 6 +-
src/test/regress/expected/event_trigger.out | 106 +++++++++++++++++++
src/test/regress/sql/event_trigger.sql | 47 ++++++++
4 files changed, 167 insertions(+), 2 deletions(-)

I had to make quiet a part of the regression tests because of the ERROR
message containing an OID, where I think it's the right error message.

I don't think we want to add complexity to the code to be able to report
the procedure name that we depend on in the event cache and that the
user just deleted while in the middle of actually running the event
trigger list we already got from the cache, right?

"Dickson S. Guedes" <listas(at)guedesoft(dot)net> writes:
> 2013/1/21 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> Another thing is that we might want to document that if a command
>> errors out, ddl_command_end will never be reached; and perhaps also
>> that if ddl_command_start errors out, the command itself will never be
>> reached. Perhaps this is so obvious as to not bear mentioning, I
>> don't know, but the thought crossed my mind that someone might fail to
>> realize it.
>
> I think that should be a mention about that in docs, someone could
> expect that ddl_command_end be reached even when
> ddl_command_start erros out, and try to use it in some way.

Yeah, I share both your views. I've been playing with event triggers for
too long to think about such documentation it seems, thanks for
reminding me about it.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support