On 10/18/2012 09:10 PM, Josh Berkus wrote:
> Daniel,
>
>> I'm not going to disagree with that, I only feel it's reasonable to
>> ask why those who react so strongly against deprecation why they think
>> what they do, and receive a clinical response, because not everyone
>> has seen those use cases. My level of interest in deprecation is only
>> as far as "if those who have to deal with the RULES implementation
>> don't want to work on it anymore in favor of other things, I think the
>> pain to users of deprecation is, from my vantage point, manageable if
>> given some time."
> Note that you have heard from one of the people maintaining RULES, who
> doesn't find them problematic to maintain (Tom). Note that the original
> hackers calling for deprecation do not work on RULEs except where they
> touch other features.
Just for kicks I decided to look and see how long ago 120 commits was on
each of the backend subdirectories. Here are the results:
[andrew@emma backend]$ for f in * ; do test -d $f && git log --format="$f: %ci" $f | sed -n -e 1,120d -e 'p;q' ;
done access: 2012-02-21 14:14:16 -0500 bootstrap: 2004-10-10 23:37:45 +0000 catalog: 2011-06-16 12:11:20 -0400
commands:2011-11-23 00:03:22 -0500 executor: 2010-02-20 21:24:02 +0000 libpq: 2009-08-29 19:26:52 +0000 main:
1998-04-0600:32:26 +0000 nodes: 2010-01-01 23:03:10 +0000 optimizer: 2011-04-08 19:19:17 -0400 parser: 2011-03-08
16:43:56-0500 po: 2003-10-04 22:50:20 +0000 port: 2006-10-13 13:59:47 +0000 postmaster: 2011-04-03 19:42:00 -0400
replication: 2011-01-10 21:53:18 +0100 rewrite: 2005-04-28 21:47:18 +0000 storage: 2011-07-08 18:44:07 +0300
tcop:2009-12-07 05:22:23 +0000 tsearch: 2007-08-22 04:13:15 +0000 utils: 2012-04-20 23:56:57 -0300
As you can see, in the case of rewrite it takes us back 7 1/2 years. I
know this is a *very* rough measure, but it still tends to indicate to
me that the maintenance burden isn't terribly high.
cheers
andrew
