On Mon, Jul 2, 2012 at 4:53 PM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Robert Haas <robertmhaas@gmail.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
