Re: Deprecating RULES

On 10/17/2012 11:31 AM, Dimitri Fontaine wrote:
> Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
>> Clearly deprecating rules implies some loss of functionality - there
>> is no exact, drop-in equivalent to something that magically rewrites
>> SQL that isn't equally baroque and problematic.
Maybe we can upgrade STATEMENT triggers to level where they
cover all practical uses of rules.

Currently we can create FOR EACH STATEMENT triggers on
INSERT OR UPDATE OR DELETE but they are pretty useless for
anything else than recording that such an even took place as
both OLD and NEW are empty for these.

Perhaps we can make them much more useful by exposing
more of the original statement to the called function.

>> If that's the bar,
>> then detractors of rules should stop wasting their breath, because the
>> bar has been set impossibly high.
> I believe an advice system is a good contender here, as already
> proposed here:
>
> http://archives.postgresql.org/pgsql-hackers/2012-10/msg00610.php
>
> See defadvice in Emacs Lisp and The Standard Method Combination of the
> Common Lisp Object System as sources of inspiration here.
>
> http://www.gnu.org/software/emacs/manual/html_node/elisp/Advising-Functions.html
> http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html
>
> It basically would be rules without the multiple evaluation risks, yet
> still the multiple evaluation feature when you need it, and with
> explicit control over it.
>
> Then if you insist on comparing to a macro facility, as we're talking
> about dynamic code rewriting, maybe we need to compare RULEs to the lisp
> style macro facility, which is nothing like a pre-processor facility
Is it something closer to decorators in some languages - that is functions
that wrap other functions in some extra functionality ?

> (in
> lisp, that's the reader, I think).
>
> Regards,