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

Re: Event Triggers reduced, v1

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Event Triggers reduced, v1
Date: 2012-07-02 20:53:17
Message-ID: m2fw99sx4y.fsf@2ndQuadrant.fr (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

Fair enough.

> 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.

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.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

In response to

Responses

pgsql-hackers by date

Next:From: Xiong HeDate: 2012-07-02 21:21:13
Subject: Re: How to extend server side encoding GBK
Previous:From: Alexander KorotkovDate: 2012-07-02 20:46:03
Subject: Re: Patch: add conversion from pg_wchar to multibyte

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