Re: unite recovery.conf and postgresql.conf

Simon,

> Everyone has their own set of requirements. I've tried hard to fuse
> those together into a useful proposal, listening to all. Please bear
> in mind that I make my living in exactly the same way you do, so you
> must surely be aware I do this solely in the common interest.

Thank you for giving us a place to start. I have seen and commented on
your compromise. Both Robert Treat and I poked holes in it. It was a
good first attempt, but not a final attempt -- your compromise proposal
was heavily skewed towards maintaining the status quo at the expense of
improving functionality. As a compromise, it was "70% Simon, 30%
everyone else".

> I don't force you to accept that proposal, but challenging it does
> require somebody to step up to the plate and work out a better
> detailed proposal rather than just restate what they personally want.

I made a proposal, which was based on modifying (and I believe,
improving) your proposal.

> We can always do nothing, which is a safe and viable option.

Not really, no. The whole recovery.conf thing is very broken and
inhibits adoption of PostgreSQL because our users can't figure it out.

You've made it pretty clear that you're personally comfortable with how
replication configuration works now, and aren't really interested in any
changes. That's certainly a valid viewpoint, but the users and
contributors who find the API horribly unusable also have a valid
viewpoint. You don't automatically win arguments because you're on the
side of backwards compatibility.

When we released binary replication in 9.0, I thought everyone knew that
it was a first cut and that we'd be making some dramatic changes --
including ones which broke things -- over the next few versions. There
was simply no way for us to know real user requirements until the
feature was in the field and being deployed in production. We would
discover some things which really didn't work and that we had to break
and remake. And we have.

Now you are arguing for premature senescence, where our first API
becomes our only API now and forever. That's a road to project death.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com