On 22 January 2013 12:02, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote:
>
> "Dickson S. Guedes" <lis...@guedesoft.net> writes:
> > 2013/1/21 Robert Haas <robertmh...@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.
I haven't followed the long discussions this patch has undergone, so
forgive me if what I'm about to ask has already been discussed and
discarded.
Would it be desirable to have ddl_command_success and
ddl_command_failed events. These would effectively be subsets to
ddl_command_end. Or should this be something handled by the event
trigger function? This would mean that you could have a command end
trigger that wouldn't necessarily fire, depending on the outcome of
the command.
Alternatively, and more elegantly, there could be a filter_variable of
(...thinks...) ERROR (?) which can have a value of true or false.
(previous paragraph seems like an awful idea now)
CREATE EVENT TRIGGER log_bad_event ON ddl_command_end WHEN ERROR IN (true)
EXECUTE PROCEDURE abort_any_command();
This, unfortunately, introducing awkwardness with the WHEN clause
restriction which doesn't accommodate simple equality. And looking at
the IN part of the syntax, it looks awful: WHEN TAG IN ('DROP
SEQUENCE' AND 'CREATE TABLE').
This looks like a confusing hybrid of a standard WHERE clause and an
IN list, but is neither. You'd expect an IN to evaluate a list of
expressions, but instead it's saying what TAGs are allowed. And this
is where it starts to read like a WHERE clause, except such logic in a
WHERE clause wouldn't make any sense as AND might suggest it must
equal both. Please, please let it not stay like this. :)
So note that I'm coming into this syntax kinda fresh, so just giving
first impressions of the current implementation.
--
Thom
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
