Re: Deprecating RULES - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Deprecating RULES
Date
Msg-id m2a9vs3dyy.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Deprecating RULES  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
> This is utter nonsense.  We can't deprecate them until we have a
> substitute that is better.  If you want to get rid of rules, build the
> replacement; don't just try to be a pain in the ass to users.

My understanding is that the main reason why RULEs are bad™ is that they
will not replace a SQL query, but possibly (or is it always) generate
multiple queries out of it, then run all of them one after the other.

Some programming languages offer much the same user level facility as
what we call RULEs, only without the hazardous behavior we all came to
hate, except for those few who actually understand it, who will then
only hate them for more detailed reasons.

That other facility is called an "advice" and allows users to attach
code to run each time a function/method/command is called, either
before, after or around the main call. In the around case, a syntactic
facility is given that will explicitly call the adviced
function/method/command, and you also have ways to change the arguments,
then of course tweak the result.

E.g an INSTEAD TRIGGER on a VIEW would be equivalent to an AROUND ADVICE
on that view, where the user code would not use the aforementioned
facility to still run the main command.

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



pgsql-hackers by date:

Previous
From: Markus Wanner
Date:
Subject: WAL_DEBUG logs spurious data
Next
From: Tom Lane
Date:
Subject: Re: Making the planner more tolerant of implicit/explicit casts