Re: Event Triggers: adding information

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Re: Event Triggers: adding information
Дата
Msg-id m2622pmnnn.fsf@2ndQuadrant.fr
обсуждение исходный текст
Ответ на Re: Event Triggers: adding information  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Event Triggers: adding information  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Re: Event Triggers: adding information  (Thom Brown <thom@linux.com>)
Re: Event Triggers: adding information  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.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@guedesoft.net> writes:
> 2013/1/21 Robert Haas <robertmhaas@gmail.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


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Prepared statements fail after schema changes with surprising error
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Event Triggers: adding information