Skip site navigation (1) Skip section navigation (2)

Re: Event Triggers reduced, v1

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Event Triggers reduced, v1
Date: 2012-07-02 20:10:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> CREATE EVENT TRIGGER name ON event_name WHEN event_trigger_variable IN
> (trigger_command_list) EXECUTE PROCEDURE func_name ()
> 1. Do we imagine a situation where a given event_name would allow more
> than one choice of event_trigger_variable?  If so, then

The only use I think is really interesting here is matching command tags
for either the main event or a sub-event of some sort. We decided not to
include any sub-commands reasoning in that first patch, that's why the
syntax is way more generic than the implementation.

You could then install an event trigger for a CREATE SEQUENCE that
happens as part of a CREATE TABLE, or a DROP COLUMN that happens as part
of a DROP TYPE, for examples.

So yes the event_trigger_variable is made to only host a tag and the
associate catalog entry make that very clear.

> pg_event_trigger needs a place to store the event_trigger_variable.

My thinking was to add another hard-coded list of tags for the other
variable, that is have a flexible syntax (no WHEN clause, a WHEN clause
with only main tag matching, a WHEN clause with both parent/main tag
matching, or only parent) that only uses two hard coded variables both
being tags matched against a static list.

The reason why it's not all in the current patch is that we decided
together that we want to revisit the sub-command semantics once we have
a basic framework in place. It's already leaky though.

> If not, then it's a noise word, and we should consider simplifying the
> syntax to something like:

> CREATE EVENT TRIGGER name ON event_name FOR (trigger_command_list)
> EXECUTE PROCEDURE func_name ()

That would have my preference, in case you would rather have a
simplified first patch, that is without any provision to expand on the
tag matching facility. Of course we won't be able to keep that syntax as
soon as we decide how to handle sub commands, which makes that decision
a lot less useful that it seems to be, in my mind.

> 2. On a related point, do we anticipate that we might eventually want
> to allow filtering by more than one event_trigger_variable in the same
> trigger?  That is, might we want to do something like this:
> CREATE EVENT TRIGGER something ON somevent WHEN thingy IN ('item1',
> 'item2') AND otherthingy IN ('foo', 'bar') EXECUTE PROCEDURE func_name
> ()

That's what I want to be able to do yes, in another step. The only two
variables I think about would be named "tag" and "toplevel", or
something equivalent ("main", "host", "user", etc).

> If so, then how do we imagine that getting stored in the catalog?

We will have to extend the catalog when we attack sub command handling,
at least I believe we will. Hence the current proposed catalog is not
yet finished. We could also already decide about sub command handling if
you think that's the only remaining thing to do in this patch; so that
it's easier down the road. At the expense of taking some more time right
now. Your call, I have the round tuitsĀ :)

Dimitri Fontaine                                        06 63 07 10 78     PostgreSQL : Expertise, Formation et Support

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2012-07-02 20:27:25
Subject: Re: Proof of concept: auto updatable views
Previous:From: Robert HaasDate: 2012-07-02 19:47:15
Subject: Re: Pg default's verbosity?

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group