Re: Event Triggers: adding information

On Wed, Jan 16, 2013 at 6:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> What was discussed at the last dev meeting was assigning a committer to
> each large patch to start with, which would reduce the risk of the
> goalposts moving that way. It seems to me that Robert's at least
> unofficially taken that role for event triggers. You should be happy,
> because if I were reviewing it I'd likely bounce the whole thing.
> I'm not convinced this will *ever* be a stable feature that doesn't
> create more problems than it fixes.

And speaking of the goalposts moving...

I don't think that's the problem, here. Rather, I think the problem
is that the design is ardently refusing to move. It might be a slight
overstatement to say that every review I've ever posted for this patch
has complained about design decisions that expose implementation
details to the user that we might want to change later, but not by
much. And yet, two years on, we've got proposals on the table to
artificially force *more* things through ProcessUtility(). There's no
particularly consistency to which things do and don't go through that
function today, and no reason whatsoever to try to force everything to
go through there. I agree with everything you say in the portion of
the email I didn't quote, and I'm pretty sure I've made similar points
more than once in the past.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company