Hi!

Would you please give me some comments about this subject? This proposal
was sent to you, attached to a previous mail, few weeks ago.
I'll appreciate so much your opinion, because we are using the
PostgreSQL for an important project at the University, and the
incorporation of this piece of code is contributing with some tests we
are carrying out. If you think this implementation is not correct or it
has some drawback, your suggestions will be welcome. I'll modify
everything you think is needed.
In addition, I'm developing this software in the context of my
undergraduate thesis. The inclusion of these features and their testing
is the objective of this thesis, then all your help is invaluable for
me!!

Perhaps you do not need the features I implemented in my research
project (activate/deactivate) but it is a central point for us. 
Besides, if the adding of this characteristic does not produce any side
effect, I think it would be added, so it would be useful for other
users. Some other DBMSs have these mechanisms.
I'll wait for your comments. Take into account that if it is needed,
I'll re-write all parts of the code you recommend me.
Best regards.

Sergio.

> 
> Hello:
> 
>  Here at the Universidad Nacional del Centro de la Provincia de Buenos Aires,
> we (myself as full professor and some other colleagues) are extensively using
> the rules of PostgreSQL. This mean that we are teaching using PostgreSQL and
> we are doing some research using it as platform for testing as well.
> 
> Naturally we do not need to explain you how useful in many contexts the rules
> are.
> 
>  However we have found two minor weaknesses:
> 
>  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.
> 
>  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.
> 
>  We ask to one of our students (Sergio Pili) to develop an implementation for
> both A and B. They has been in operation since Dec 2000 in version  7.0.3.
> Lately, Sergio ported his implementation to version 7.1.3. We
>  think that this update to PostgreSQL will strenght the power of the rules
> rewriting system.
> 
>  Attached Sergio's patch for version 7.1.3.
> 
> Jorge H Doorn
Fri, 26 Oct 2001 20:01:53 -0300
Sergio Pili <sergiop@sinectis.com.ar>
[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

Fri, 26 Oct 2001 20:45:23 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [Fwd: PostgreSQL new commands proposal] 