On 10/17/12 12:57 PM, Daniel Farina wrote: > I'll have to register my disagreement then, in the special case where > a feature becomes so obscure that many people don't have a wide-spread > intuition at what it's good at or used for. Tom also said "build the > replacement," and without itemization of use cases, I don't even know > what that would look like -- perhaps such knowledge is assumed, but I > think it's assumed wrongly, so perhaps there just needs to be some > education. At best you could define what to build somewhat > tautologically from the mechanism used by RULES, and that's not a very > good way to go about it, methinks.
Well, there are the cases for which RULEs are actually the superior/only mechanism (probably a fairly small set) and the cases where they are not, but are used anyway (a much larger set). For the latter group, those cases need to be (a) identified, and (b) migration documented. For example, one can currently create an ON UPDATE rule to make a view updatable. It is now also possible to create a trigger to do the same thing, and its results would be more predictable. However, nobody has documented how one would migrate and existing UPDATE rule to a new ON UPDATE trigger. Putting it as "Andrew and Josh need to enumerate these cases, or forever be silent" is quite unfair to our users. Andrew and I hardly represent the entire scope of PostgreSQL app developers. Enumerating the cases, finding replacements for them, and documenting migrations needs to be a group effort. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
