Re: Deprecating RULES - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Deprecating RULES
Date
Msg-id m2ehkxmome.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Deprecating RULES  (Peter Geoghegan <peter@2ndquadrant.com>)
Responses Re: Deprecating RULES  (Hannu Krosing <hannu@krosing.net>)
Re: Deprecating RULES  (John R Pierce <pierce@hogranch.com>)
List pgsql-hackers
Peter Geoghegan <peter@2ndquadrant.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. 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 (in
lisp, that's the reader, I think).

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support



pgsql-hackers by date:

Previous
From: Markus Wanner
Date:
Subject: Re: Global Sequences
Next
From: chinnaobi
Date:
Subject: Re: How to avoid base backup in automated failover