Re: WAS: [Fwd: PostgreSQL new commands proposal]

Поиск
Список
Период
Сортировка
От Stephan Szabo
Тема Re: WAS: [Fwd: PostgreSQL new commands proposal]
Дата
Msg-id 20011126060937.P10034-100000@megazone23.bigpanda.com
обсуждение исходный текст
Ответ на WAS: [Fwd: PostgreSQL new commands proposal]  (Sergio Pili <sergiop@sinectis.com.ar>)
Список pgsql-hackers
On Thu, 15 Nov 2001, Sergio Pili wrote:

> We are developing a project at the Universidad Nacional del Centro, in
> Argentina. Sergio Pili, who has communicated with you previously, is
> working with us. We are interested in the feature he is implementing:
> rule activation and deactivation.
>
> With respect to the safeness of this deactivation, we can say that:
>
> - It can be executed just only from the action of the rule.
> - The deactivated rule continues deactivated while the rewriting of the
> query which executed that deactivation is done. This means that the
> deactivation does not affect other queries. Moreover, the rule is
> automatically reactivated when the rewrite process is finished.
> - This feature avoids recursive activation.
>
> Example:
>
> CREATE TABLE A (aa int primary key, a int, b int);
> CREATE TABLE B (bb int primary key,a int, b int);
>
> CREATE RULE upd_b AS ON UPDATE TO B
> WHERE
>         NOT EXISTS (SELECT *
>         FROM A
>         WHERE  A.a = NEW.a
>                 AND A.b = NEW.b )
> DO INSTEAD
>         SELECT pg_abort_with_msg('No existen registros con a = '||
>         NEW.a || ' b = ' || NEW.b || ' en la tabla A');
>
> CREATE RULE upd_a AS ON UPDATE TO A
> DO
> UPDATE B SET a = NEW.a, b = NEW.b
> WHERE a = OLD.a
> AND b = OLD.b;

Since you asked for comments, I don't think this is
a terribly compelling example. It looks alot like a
multicolumn foreign key with on update cascade to
me except that it's defined against a non-unique
key (meaning the update rule may not do what you really
want if there are duplicate rows in a that are matched),
the error message is more specific, and it looks less
transaction safe than the current foreign key
implementation (imagine one transaction deleting
a row in A and another updating B to point to that
row).  Also, turning off the rule in this case is
wrong, since if something else (a before trigger
for example) modifies the row in A before it's inserted
I'm pretty sure you end up with a row in B that
doesn't match. I think there are probably useful
applications of turning off rule expansion, but
this isn't it.




В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Lee Crampton"
Дата:
Сообщение: Re: Setting up MAKE file for Postgres and C++/Newbie question
Следующее
От: Alessio Bragadini
Дата:
Сообщение: 7.2beta3 on Digital Alpha