On Fri, Jun 01, 2007 at 11:08:50PM +0200, Alexander Staubo wrote:
> That doesn't make any sense. As a database *user* it's my prerogative
> to criticize the bits that make my life painful.
Sure. And as a user of free software, it is your prerogative to
propose a way that the software can be modified to make it do what
you want, and to do the work to so modify it. Does this mean you are
offering?
> For example, there is clearly an opportunity to implement the
> appropriate hooks in PostgreSQL that can be used *if they are
> available*; otherwise, on unpatched/older systems, require the use of
> the slonik command.
I don't know that that is clear at all. To begin with, one would
have to get agreement on what those hooks would be. If you look on
the pgfoundry site, you'll note that I set up a project there to try
to get such a list of hooks defined. It went nowhere: everyone who
was working on replication said it was premature and impossible to do
this in advance and such like. Moreover, what you are suggesting is
a _massive_ increase in the complications of the code, because it
suggests to me that you want DDL to happen as easily as it does in
single-node cases. But it's not that easy, which is another part of
the reason DDL is handled specially. If you don't know what the hard
parts are, I suggest you go and read the rather detailed original
concept document that Jan put together for the community prior to
starting work on the system. But just as a teaser: what do you do if
your DDL on the local node has succeeded, and you added additional
data in the same transaction, but the DDL fails for some reason on a
remote node? Note that this one isn't even one of the actually
tricky cases.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
A certain description of men are for getting out of debt, yet are
against all taxes for raising money to pay it off.
--Alexander Hamilton