Re: Deprecating RULES

[I'm replying to Robert's message only because it is the latest on
the thread; I'm actually kinda replying to the whole thread in
general.]

When catching up on a backlog, one would hope that any thread
comprising more than 5% of said backlog would be more constructive.
:-(

As someone coming in late with no skin in the game, here are my
observations:

(1) A suggestion was made by someone who was unaware of any actual
productive uses of rules (outside of the red herring of the internal
implementation detail regarding views -- which many other products
manage to provide without rules) that we clean up what was assumed to
be old baggage. I viewed the suggestion as having been made in more
or less the same spirit as suggesting cleaning up include directives
which weren't really needed or eliminating the storage manager layer:
sort of a bother, unfortunately some risk, but resulting in cleaner
and more maintainable code in the long run.

(2) My initial gut reaction to the suggestion was positive, as my
only attempt at using rules resulted in some very astonishing and
dangerous behavior in testing. When I asked about it I seem to
remember being told that rules were an old legacy feature which had
no real use and would generally bite you badly when an unexpected
type of query was run against the table with the rule. This matched
my later experiences of seeing people ask questions when they were
bitten or having problems getting rules to work as intended.

(3) A number of people then responded with claims that rules were
useful, but when those ignorant of such uses were curious about
examples, were either given hand-wavey descriptions or angry-sounding
challenges to prove that there were no such uses.

(4) Subsequent discussion has produced a few shadowy hints at what
such uses look like, with the most concrete being a one-time load of
partitions, for which rules are apparently one or two orders of
magnitude faster than FOR EACH ROW truggers. There was also a mention
of writing to a log table being easier. Out of 100+ messages on this
thread, I can't recall anything else that wasn't pretty vague.

(5) Even some of those opposing deprecation say they would like to
see rules go away eventually, once all of the (unspecified) uses have
better alternatives.

(6) There has been an assertion that it is impossible for the people
on the -hackers list to properly identify and enumerate the valid
real-world use-cases for rules; that we need to draw such information
from a wider group.

(7) There has been an aknowledgement that the documentation neither
makes clear where rules might really be useful, nor how they can
produce surprising results, including eating data. (Brainz aside,
I assume we can all agree that a rule can surprise you by eating
*data* you didn't expect it to?)

I can't think of anything I got out of the thread beyond the above.

Given the above, it seems that the first priority should be doing
something about the documentation.

Since as far as I can tell nobody has *any* trouble coming up with
dangerous uses of rules, the hold-up on getting anything else done is
in getting a wide sampling of appropriate and safe usage.

I invite anyone who thinks rules should stay permanently to write a
blog entry on "Why Rules Are a Cool Feature." In particular, I would
love to see it include useful examples of what Andrew calls
"non-trivial" rules on a blog page he wrote:

 http://blog.rhodiumtoad.org.uk/2010/06/21/the-rule-challenge/

Failing that, how do we collect a broad enough sampling of current
usage to be sure we know when we have alternatives for every current
valid usage?

-Kevin