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: (view raw, whole thread or download thread mbox)
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
- 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
The Enterprise PostgreSQL Company

In response to


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-2017 The PostgreSQL Global Development Group