On Wed, Jan 16, 2013 at 6:14 PM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
