Thread: Re: [HACKERS] TRIGGER with WHEN clause

KaiGai Kohei wrote:
> Itagaki Takahiro wrote:
>
>> Here is a updated TRIGGER with WHEN cluase patch.
>> I adjusted it to work with recent parser cleanup (*OLD* and *NEW*).
>>
> I would like to volunteer for reviewing the patch in RR-stage.
> It seems to me an interesting feature.
>
That one is now yours. It would be nice if you subscribed to the
pgsql-rrreviewers list if you're not already on there, but it's not
really necessary if you just want to grab that one patch and report on
it to pgsql-hackers.

Dimitri Fontaine had expressed some interest in that one as well.
Dimitri, since KaiGai wants specifically to take a shot at that one, I'm
going to assign you the "Syntax for partitioning" patch you said was
your second choice instead.

--
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com  www.2ndQuadrant.com

Greg Smith wrote:
> KaiGai Kohei wrote:
>> Itagaki Takahiro wrote:
>>
>>> Here is a updated TRIGGER with WHEN cluase patch.
>>> I adjusted it to work with recent parser cleanup (*OLD* and *NEW*).
>>>
>> I would like to volunteer for reviewing the patch in RR-stage.
>> It seems to me an interesting feature.
>>
> That one is now yours. It would be nice if you subscribed to the
> pgsql-rrreviewers list if you're not already on there, but it's not
> really necessary if you just want to grab that one patch and report on
> it to pgsql-hackers.

I tagged "Ready for Committer" flag on the patch, so my hands are now getting
free. :-)

I can find some patches which still don't have any feedbacks on the CF page.
  https://commitfest.postgresql.org/action/commitfest_view?id=4

If RR-reviewer's availability is not enough now, I will be able to help
review the patches as long as my capability allows it.


In addition, I'm strongly finding volunteers to review the SE-PostgreSQL/Lite
patch. At the first view, it may seem to you a bit large patch, but 40%
of them are documentations (except for source code comments) and test cases.
I believe rest of code will consist of enough simple implementations for
average pgsql-hackers, because I separated a lot of features from full
functionalities revision, as follows:
 - No access controls except for database, schemas, tables and columns
 - No row-level granularity in access controls
 - No caches for access control decisions
 - No security identifier in HeapTupleHeader and No new system columns.

The following code example will help understand its design and implementation.
  http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/src/backend/security/sepgsql/README#784

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>