Simon Riggs wrote:
> On Tue, Oct 11, 2011 at 3:29 PM, Bruce Momjian <bruce@momjian.us> wrote:
>
> > As much as I appreciate Simon's work in this area, I think we are still
> > unclear if keeping backward-compatibility is worth the complexity
> > required for future users. ?Historically we have been bold in changing
> > postgresql.conf settings to improve clarity, and that approach has
> > served us well.
>
> You raise a good point. First, thank you for the respectful comment;
> my viewpoint is not formed from resistance to change per se, even if
> may appear to be so. Thank you for raising that possibility to allow
> me to explain and refute that.
>
> I am genuinely concerned that we show respect to downstream software
> that uses our APIs and have no personal or corporate ulterior motive.
>
> Most people are used to the 3 year cycle of development on which
> SQLServer and Oracle have now standardised. Our 1 year cycle provides
> a considerable benefit in agility, but it also provides for x3
> complexity in release management and a continual temptation to change
> for no good reason. I want to encourage people to adopt our APIs, not
> give them a headache for attempting to do so. We know that software
> exists that follows the previous API and we should take steps to
> deprecate that across multiple releases, with appropriate notice, just
> as we do in other cases, such as standard conforming strings where our
> lack of boldness is appropriate.
Well, let me be specific. Around 2003 to 2006, we added many new
configuration parameters for logging, which required renaming or
removing older parameters. There really wasn't a smooth way to allow
for this to be done without impacting users, and the current system we
have enjoyed since 2006 is logical only because we made the changes
necessary.
We can look at trying to phase changes in, but often the phasing becomes
more complicated that just doing the change. Logging parameter changes
were easier because it was assumed logging was an admin-only task, as I
assume pitr and replication are as well. Standard conforming strings
was tricky because it was more user-facing, or certainly SQL-facing.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +