On 12/12/2011 11:32 AM, Robert Haas wrote:
I haven't yet thought about your specific proposal here in enough to have a fully-formed opinion, but I am a little nervous that this may turn out to be one of those cases where the obvious API ends up working less well than might have been supposed.
There's another cautionary tale from the sepgsql history worth mentioning here, which surely I don't have to remind you about. Making the goal for a first shippable subset include proof you can solve the hardest problems in that area can lead to a long road without committing anything. With sepgsql, that was focusing on the worst of the ALTER TABLE issues. As Dimitri was pointing out, the name change to Command Triggers includes a sort of admission that DDL Triggers are too hard to solve in all cases yet. We shouldn't be as afraid to introduce APIs that are aimed at developers who currently have none.
Yes, there's a risk that will end with "...and this one has to be broken in the next release because of this case we didn't see". We can't be so afraid of that we don't do anything, especially when the users who would be impacted by that theoretical case are currently suffering from an even worse problem than that. To provide the big picture infrastructure tools that people are desperate for now, PostgreSQL needs to get a lot more agile when it comes to revving hooks whose main consumers are not regular application programs. They're the administrators of the system instead.
I know what I was just rallying against is not what you were arguing for, you just triggered a stored rant of mine. [Bad trigger joke goes here] Regardless, thoughts on where the holes are here are appreciated.
-- Greg Smith 2ndQuadrant US g...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
