[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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
