On Tue, Jun 14, 2011 at 1:43 PM, Jaime Casanova <ja...@2ndquadrant.com> wrote: > On Tue, Jun 14, 2011 at 12:25 PM, Greg Smith <g...@2ndquadrant.com> wrote: >> >> Anyway, I want a larger change to pg_stat_activity than this one > > Well, Simon recomended to have a big bag of changes that justify break > tools... and you have presented a good one item for that bag... > Maybe we should start a wiki page for this and put there all the > changes we want to see before break anything? > > for example, a change i want to see is in csvlog: i want a duration > field there because tools like pgfouine, pgsi and others parse the > message field for a "duration" string which is only usefull if the > message is in english which non-english dba's won't have
There are real problems with the idea of having one release where we break everything that we want to break - mostly from a process standpoint. We aren't always good at being organized and disciplined, and coming up with a multi-year plan to break everything all at once in 2014 for release in 2015 may be difficult, because it requires a consensus on release management to hold together for years, and sometimes we can't even manage "days". But I don't think it's a bad idea to try. So +1 for creating a list of things that we think we might like to break at some point. It might be worth trying to do this in the context of the Todo list - come up with some special badge or flag that we can put on items that require a compatibility break, so that we can scan for them there easily. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
