On Tue, Jun 14, 2011 at 1:43 PM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
> On Tue, Jun 14, 2011 at 12:25 PM, Greg Smith <greg@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
