Sergio Pili <sergiop@sinectis.com.ar> writes:
>> A) It is related with situations where more than one rule is involved
>> and the seccond one requires completion of the first one. In our sort
>> of problems this happens frequently. This can be solved adding the
>> notion of "disablement" of the first rule within the re-writing of
>> the second rule when the first rule is not required since the
>> knowledge of the action of the second rule allows it. To do this, the
>> addition of two new commands is proposed: DEACTIVATE/ACTIVATE RULE.
You haven't made a case at all for why this is a good idea, nor whether
the result couldn't be accomplished with some cleaner approach (no,
I don't think short-term disablement of a rule is a clean approach...)
Please give some examples that show why you think such a feature is
useful.
>> B) The lack of a transaction abortion clause. (Chapter 17 Section 5
>> PostgreSQL 7.1 Programmer�s Guide)
>> The addition of the function
>> pg_abort_with_msg(text)
>> wich can be called from a SELECT is proposed.
This seems straightforward enough, but again I'm bemused why you'd want
such a thing. Rules are sufficiently nonprocedural that it's hard to
see the point of putting deliberate error traps into them --- it seems
too hard to control whether the error occurs or not. I understand
reporting errors in procedural languages ... but all our procedural
languages already have error-raising mechanisms. For example, you could
implement this function in plpgsql as
regression=# create function pg_abort_with_msg(text) returns int as
regression-# 'begin
regression'# raise exception ''%'', $1;
regression'# return 0;
regression'# end;' language 'plpgsql';
CREATE
regression=# select pg_abort_with_msg('bogus');
ERROR: bogus
regression=#
Again, a convincing example of a situation where this is an appropriate
solution would go a long way towards making me see why the feature is
needed.
regards, tom lane