Re: Event Triggers reduced, v1 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Event Triggers reduced, v1
Date
Msg-id CA+TgmoZBg0XKTV761-3BEvFwNmdFqaMY4N2J0XMJT911LVzK+g@mail.gmail.com
Whole thread Raw
In response to Re: Event Triggers reduced, v1  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Event Triggers reduced, v1
Re: Event Triggers reduced, v1
List pgsql-hackers
On Mon, Jul 2, 2012 at 4:10 PM, Dimitri Fontaine <dimitri@2ndquadrant.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


pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Patch: add conversion from pg_wchar to multibyte
Next
From: Tom Lane
Date:
Subject: Re: Proof of concept: auto updatable views