From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | greg(at)turnstep(dot)com ("Greg Sabino Mullane"), pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Rules: A Modest Proposal |
Date: | 2009-10-05 13:53:56 |
Message-ID: | 87pr92lzez.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>>>> "Greg" == "Greg Sabino Mullane" <greg(at)turnstep(dot)com> writes:
>> They're mostly a foot-gun.
Greg> Lots of things in Postgres could be considered potential foot
Greg> guns. Frankly, I don't think rules are even near the top of
Greg> such a list. Can you give examples of rule foot guns?
There are so many it's hard to know where to start.
Here are a couple of the more common ones:
1) any reference in an insert rule to NEW.col where col has a volatile
default, or the expression in the insert statement was volatile, or
the expression's value is changed by the insert, will do the wrong
thing:
create table t (a integer);
create table t_log (a integer);
create rule t_ins AS ON insert TO t do also insert into t_log values (NEW.a);
insert into t values (floor(random()*1000)::integer);
select * from t;
a
----
33
(1 row)
select * from t_log;
a
-----
392
(1 row)
(think "nextval" or "uuid_generate_*" for more realistic examples)
2) any rule with multiple actions, each action is affected by the results of
the previous ones. A classic example of this is in the use of OLD in
delete or update rules; OLD _does not return a row_ if a previous action
in the rule deleted the row or updated it so that it no longer matches.
--
Andrew (irc:RhodiumToad)
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2009-10-05 14:09:17 | Re: Rules: A Modest Proposal |
Previous Message | Tom Lane | 2009-10-05 13:49:43 | Re: Making hash indexes worthwhile |