Re: DO INSTEAD in rule
От | Tom Lane |
---|---|
Тема | Re: DO INSTEAD in rule |
Дата | |
Msg-id | 21119.1073238506@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | DO INSTEAD in rule (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Ответы |
Re: DO INSTEAD in rule
|
Список | pgsql-sql |
Tatsuo Ishii <t-ishii@sra.co.jp> writes: > In the last SELECT I exepcted j = 0, rather than j = 1 since I use DO > INSTEAD in the rule and the default value for j is 0. Am I missing > something? > CREATE rule t1_ins AS ON INSERT TO t1 > WHERE (EXISTS (SELECT 1 FROM t1 > WHERE i = new.i)) > DO INSTEAD UPDATE t1 SET j = j + 1 > WHERE i = new.i; Hm. The problem is that the rule query runs after the INSERT and so it sees the inserted row as something to update. The logic is essentially if (not (EXISTS ...)) then do the INSERT;if (EXISTS ...) then do the UPDATE; and the second command sees the inserted row as existing, so it updates it. Without an if-then-else kind of control structure for the executor, I'm not sure we can do better. (Even with one, I'm not sure how to handle cases where the INSERT inserts multiple rows.) Consider using a trigger instead of a rule to do this. Or, accept that the UPDATE will happen unconditionally, and start J off one less than it should be. Note that either solution will have race conditions if multiple processes try to insert the same row at the same time. There are discussions in the archives about how to avoid that, but I'm not sure anyone found a really satisfactory answer that didn't involve an unpleasant amount of locking. regards, tom lane
В списке pgsql-sql по дате отправления: