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

Re: Event Triggers reduced, v1

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Event Triggers reduced, v1
Date: 2012-07-02 21:23:02
Message-ID: CA+TgmoZCjjS1uujeqz4h1UswUZSZe9VvHy2zRokyZ7Cwvi095w@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Jul 2, 2012 at 4:53 PM, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> 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?
>
> Given what I foresee, simply having another columns in there named
> evtstags with the exact same content as evttags would be the simplest
> and most natural implementation, really.

That seems a lot less general for no particular gain.

> I don't foresee more generic needs here, unless you can convince me that
> we need both a. a full stack of arbitrarily nested commands and b. a way
> to match and target any level of that stack.

Well, let's take the example of an ALTER TABLE command.  You could
want to match on:

- the type of object the user mentioned in the command (did he write
ALTER TABLE or ALTER VIEW?)
- the type of object actually being modified (could differ if he used
ALTER TABLE on a view, or visca versa)
- the particular ALTER TABLE subcommand in use (e.g. SET STATISTICS)

I suspect there are other examples as well.  If we pick the 2-D list
representation I suggested, or something like it, we can easily
accommodate these kinds of filters without having to whack the catalog
representation around any further.  That seems pretty appealing.

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

In response to

Responses

pgsql-hackers by date

Next:From: Peter GeogheganDate: 2012-07-02 21:52:17
Subject: Re: enhanced error fields
Previous:From: Xiong HeDate: 2012-07-02 21:21:13
Subject: Re: How to extend server side encoding GBK

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