On 12/13/2011 09:59 AM, Robert Haas wrote:
Well, the problem is that just because something better comes along doesn't mean we'll actually deprecate and remove the old functionality.
The examples you gave fall into three groups, and I think it's useful to demarcate how they're different. Please pardon me going wildly off topic before returning back.
If you drop xml2 or rules, people lose something. It's primarily the PostgreSQL developers who gain something. You can make a case that people who won't get sucked into doing something wrong with rules one day will gain something, but those people are a future speculation; they're not here asking to be saved for a problem they don't know will happen yet. This sort of deprecation battle is nearly impossible to win. One of the reasons I placed a small bet helping sponsor PGXN is that I hope it allows some of this should be deprecated stuff to move there usefully. Let the people who use it maintain it moving forward if they feel it's important.
The recovery.conf change and other attempts to reorganize the postgresql.conf are in a second category. These break scripts, without providing an immediate and obvious gain to everyone. Some say it's better, some say it's worse, from the list traffic it seems like a zero-sum game. The burden is on the person advocating the change to justify it if there's not a clear win for everyone. You might note that my latest attitude toward this area is to provide the mechanism I want as a new option, and not even try to argue about removing the old thing anymore. This lets implementation ideas battle it out in the wild. Let's say a year from now everyone who hasn't switched to using a conf.d dirctory approach looks like an old stick in the mud. Then maybe I pull the sheet I have an enormous bikeshed hidden behind, waiting for just that day.[1]
When VACUUM FULL was rewritten, it took a recurring large problem that has impacted a lot of people, and replaced with a much better thing for most cases. A significantly smaller number of people lost something that was slightly useful. There weren't as many complaints because the thing that was lost was replaced with something better by most metrics. Different, but better. This third category of changes are much easier to sell. We have another such discontinuity coming with pg_stat_activity. The changes Scott Mead's patch kicked off make it different and better. Anyone who has a tool using the old thing can look at the new design and say "well, that makes the whole 'what state is the connection in' logic I used to worry about go away; that's progress even if it breaks my old scripts". People need to get something that offsets the breakage to keep griping down. Anyone who argues against those sort of changes has a challenging battle on their hands.
If there is a Command Trigger implementation that Slony etc. use, and we discover a limitation that requires an API break, that's OK so long as it's expected that will fall into the last category. Breakage to add support for something new should be a feature clearly gained, something lost, and with a net benefit to most consumers of that feature. People accept it or block obvious forward progress. We don't want to get too confused between what makes for good progress on that sort of thing with the hard deprecation problems. (Not that I'm saying you are here, just pointing out it happens)
Dimitri says that he wants it so that we can add support for CREATE TABLE, ALTER TABLE, and DROP TABLE to Slony, Bucardo, and Londiste. My fear is that it won't turn out to be adequate to that task, because there won't actually be enough information in the CREATE TABLE statement to do the same thing on all servers.
These are all good things to look into, please keep those test set ideas coming and hopefully we'll get some more input on this. But let's say this rolls out seeming good enough, and later someone discovers some weird index thing that isn't supported. If that's followed by "here's a new API; it breaks your old code, but it allows supporting that index you couldn't deal with before", that's unlikely to get shot down by that API's consumers. What you wouldn't be able to do is say "this new API doesn't work right, let's just yank it out". Your concerns about making sure at least the fundamentals hold here are on point though.
[1] Look at that, I can now say that 100% of the programs I compose e-mail with now have "bikeshed" added to their dictionary. I don't bother with this often, but there's entries for "PostgreSQL" and "committer" there too.[2]
[2] Would you believe a Google search for "committer" shows the PostgreSQL wiki page as its second hit? That's only behind the Wikipedia link, and ahead of the FreeBSD, Chromium, Apache, and Mozilla pages on that topic.
-- Greg Smith 2ndQuadrant US g...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
