Re: [Fwd: PostgreSQL new commands proposal]

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