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:
>> 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.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Peter Geoghegan||Date: 2012-07-02 21:52:17|
|Subject: Re: enhanced error fields|
|Previous:||From: Xiong He||Date: 2012-07-02 21:21:13|
|Subject: Re: How to extend server side encoding GBK|