On Wed, Nov 22, 2006 at 08:21:23PM +0100, Markus Schiltknecht wrote:
>
> For Postgres-R, I definitely don't want to settle for any hooks, yet,
> because I want to keep flexible. Hooks would only get into my way and
> serve no purpose.
Let me make the following argument to the contrary. This is a
rationale argument for the other discussion, and not a discussion of
the hooks themselves, so I think it's still appropriate for -hackers.
The reason to write down what the _requirements_ are for hooks is so
that the community can get to work on any of the general approaches
to replication that they want. These hooks might, in fact, turn out
to be nothing more than a layer of indirection in the core PostgreSQL
code.
The reason the earlier attempts at Postgres-R didn't ever make it out
of testing was precisely, I argue, because there just wasn't an
interface for the rest of the PostgreSQL project (maybe not
interested in replication) to keep stable. So merely keeping up with
the pace of change in the core code turned into a significant
undertaking. Those are cycles stolen from the more useful work of
making the replication code work better.
The same thing is true of other pieces that have fallen by the side:
because the whole of the PostgreSQL project moves so quickly, a small
number of people working on a large feature set in relative isolation
can end up spending way too much time keeping up with the core, and
not enough time working on the features they desire. The result is a
loss to everyone.
So that's why I was trying to outline what, at least, the
requirements are.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
Users never remark, "Wow, this software may be buggy and hard
to use, but at least there is a lot of code underneath." --Damien Katz