On Thu, Oct 18, 2012 at 1:55 PM, Andrew Dunstan <and...@dunslane.net> wrote: > > On 10/18/2012 01:11 PM, Daniel Farina wrote: > >> Here's another use case that in my history with RULES that didn't seem >> to pan out so well: In my recollection, one way to use rules is to >> retarget operations that happen against a view and move them to a >> table, and as I recall to make this work as one expected one had to >> have a very wordy RULE (for UPDATEs) with a litany of (fairly simple) >> equality and not-null conditions to make it work as one would expect >> (to not under-constrain the UPDATE). This became a maintenance >> headache whenever attributes were added to the underlying relation. > > > > Yes, but you also get a similar headache with a trigger. Unless you're VERY > careful you can get a trigger failure by adding an attribute, and an almost > guaranteed one by removing an attribute. It's true that the language for > specifying the operations is more expressive, but no matter what mechanism > you use, changing the shape of the objects can get you into trouble. > > I've never said that rules are perfect, nor that they should be used > whenever possible. What I have said is that there are known cases where they > are the best solution currently available. I still think that.
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." I also want to be very clear that I know my vantage point is skewed, but I feel like exposing what assessment of user activity I can to -hackers is important, and the best I can do when it comes to considering topics like these. -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
