Skip site navigation (1) Skip section navigation (2)

Re: [Fwd: PostgreSQL new commands proposal]

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Sergio Pili <sergiop(at)sinectis(dot)com(dot)ar>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [Fwd: PostgreSQL new commands proposal]
Date: 2001-10-27 00:45:23
Message-ID: 29585.1004143523@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Sergio Pili <sergiop(at)sinectis(dot)com(dot)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 Programmers 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

In response to

pgsql-hackers by date

Next:From: Lamar OwenDate: 2001-10-27 01:04:54
Subject: Re: 7.2b1 ...
Previous:From: Thomas LockhartDate: 2001-10-27 00:32:51
Subject: Re: 7.2b1 ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group