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 greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
