Re: Deprecating RULES

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(at)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-06 00: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