Re: Event Triggers reduced, v1

On Mon, Jul 2, 2012 at 4:10 PM, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
>> 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 :)

I'd really like to not have to change the catalog again in every
patch, because if we do that then we are just saying we're going to
rewrite this patch completely every time we want to add a new feature,
which kind of defeats the purpose IMHO.

So let's try to hammer something out now. The obvious thing that
occurs to me is to have a column in the catalog that is a 2-D array of
text, with the first element of each array being something like "tag"
or "subtag" (i.e. event_trigger_variable) and the remaining array
elements being a list of legal values. That is:

WHEN thingy IN thingy IN ('item1', 'item2') AND otherthingy IN ('foo', 'bar')

would be represented as this array:

{{thingy,item1,item2},{otherthingy,foo,bar}}

This would allow us to support 0 or more WHERE clauses, each of the
form "thing IN (value1, value2, ...)". Is that general enough for
every use case that you can foresee, or do we need more?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company