Re: 7.1 bug fix question
От | Steve Wampler |
---|---|
Тема | Re: 7.1 bug fix question |
Дата | |
Msg-id | 3ADF1A9E.AA3FB24F@noao.edu обсуждение исходный текст |
Ответ на | 7.1 bug fix question (Steve Wampler <swampler@noao.edu>) |
Список | pgsql-general |
Tom Lane wrote: > > Steve Wampler <swampler@noao.edu> writes: > > One of the listed bug fixes is: > > Disallow INSERT/UPDATE/DELETE on views > > Can some one give me a little insight on what this > > implies? > > It means that if you try to do INSERT/UPDATE/DELETE on a view that > doesn't have a rule to translate that action to something else, the > system will complain (rather than applying the action to the hidden > table underlying the view, as it used to do with confusing results). > > > In particular, I currently (pg 7.0.3) have views with > > trigger functions on insert and update that trap the > > action and recast it to a table (after doing some checks). > > > Will this still work with 7.1? > > Yes. As long as you have appropriate rules, this change won't affect > you at all. Well, it looks like I got bit by this after all. Can someone show me a rule to attach to a view ("attributes") to invoke a trigger function (insert_or_update)? The trigger function maps the update into either an insert or an update on the underlying table ("attributes_table") depending on whether the row already exists or not. This was working under 7.0.3 (naturally, since insert/update/delete were allowed on views without explicit rules). I guess I'm looking for a rule that restores the behavior from 7.0.3... I didn't see anything in the programmers guide for 7.1 that helped me understand how to get the trigger function to get called. (Probably my lack of understanding of what an "action" can be.) Thanks! -- Steve Wampler- SOLIS Project, National Solar Observatory swampler@noao.edu
В списке pgsql-general по дате отправления: