Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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:
> 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.
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.
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
In response to
pgsql-hackers by date
|Next:||From: Xiong He||Date: 2012-07-02 21:21:13|
|Subject: Re: How to extend server side encoding GBK|
|Previous:||From: Alexander Korotkov||Date: 2012-07-02 20:46:03|
|Subject: Re: Patch: add conversion from pg_wchar to multibyte|