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@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