Re: question on update/delete rules on views
question on update/delete rules on views
I am trying to create multiple views of a single table so different groups of people have access to different subsets of records within the table. So I need a complete set of rules for each view. My rules for select and insert seem to work just fine, but the update/delete rules hit all the records instead of being limited by the "where" clause in my calling query.
I'm not sure if I'm doing something wrong or if I've found a bug. Any help would be greatly appreciated. Here is a script that demonstrates the problem:
--Create our table
drop table a;
create table a (
one char(2),
two char(2),
three int4,
primary key (one,two)
);
--Insert some data to work with
insert into a values ('aa','xz', 10);
insert into a values ('ab','xz', 12);
insert into a values ('ac','xz', 20);
insert into a values ('ad','xz', 11);
insert into a values ('ae','xz', 15);
insert into a values ('ai','xz', 30);
--Now view the data
select * from a;
--Now this view should have a valid rule for all operations
drop view view_a;
create view view_a as select one, two from a;
create rule view_a_r_insert as on insert to view_a
do instead
insert into a (one, two, three)
values (new.one, new.two, 100);
--Test the insert rule
insert into view_a (one, two) values ('az','xy');
create rule view_a_r_update as on update to view_a
do instead
update a set two = new.two;
--Test the update rule
update view_a set two = 'mn' where one = 'az';
--Notice all records got updated--not just the one where one = 'az'
select * from a;
According to the manual (chapter 42), when you have a view with no rule qualification but and instead clause, the resultant parsetree should include the rule action, plus the qualification from the original (calling) query. Doesn't this mean that my "where one = 'az'" clause should be appended to the update rule so that only one record gets updated? Or am I missing something?
Re: question on update/delete rules on views
Brook Milligan wrote: > create rule view_a_r_update as on update to view_a > do instead > update a set two = new.two; > > The problem is that your INSTEAD UPDATE rule is not constrained in any > way; it DOES hit every row. Instead, do something like: > > create rule view_a_r_update as on update to view_a > do instead > update a set two = new.two > where id = old.id; > > where id is a primary key in your table. > Thanks for the help. The problem with your suggestion is the view has to anticipate which column(s) the calling query wants to look at. What if the calling query has not specified the primary key in its where clause? In our real case, the table has many columns. There are a variety of queries that act on the table based on a variety of conditions in a variety of columns. I'd like to avoid having to have a separate rule or view for every possible where combination. Maybe that is not possible, but the manual seems to say it should work, so that's why I'm asking the question.
Re: question on update/delete rules on views
> create rule view_a_r_update as on update to view_aThanks Brook. That makes sense to me now. Here's the test file that demonstrates the proper (or at least a better) approach. I'll post the whole thing for the benefit of others (who wish to avoid looking as stupid as me). Even with all the examples of rules and views in the docs, I had a hard time finding an example of a view that simply gives fully functional access to a single underlying table.
> do instead
> update a set two = new.two
> where id = old.id;
>
> where id is a primary key in your table.I think you misunderstand what is going on. The original WHERE clause
(in your query) defines a set of tuples to which the UPDATE rule will
be applied. In the example above, each of those tuples will have a
primary key value (old.id in that case) and the matching field(s) in
table (or view) a will be changed as dictated by the rule. Thus, for
every tuple selected by your WHERE clause, the corresponding tuple in
the underlying table will be updated. Note that as many fields as you
wish to allow updates on can be included in the set ... part of the
rule; any that are not different will just be changed to the same
value (i.e., there will be no effect). Consequently, you don't need
lots of rules for every combination of columns (unless there are other
reasons to restrict the set of columns modifiable by different views).
BTW, do you have an equally sensible explanation of how the "where condition" that is part of the rule syntax differs from the where clause that comes after the "do instead"?
drop table a;
create table a (
one char(2),
two char(2),
three int4,
primary key (one,two)
);
insert into a values ('aa','xz', 10);
insert into a values ('ab','xz', 12);
insert into a values ('ac','xz', 100);
insert into a values ('ad','xz', 11);
insert into a values ('ae','xz', 15);
insert into a values ('ai','xz', 30);
drop view view_a;
create view view_a as select one, two, three from a;
create rule view_a_r_insert as on insert to view_a
do instead
insert into a (one, two, three)
values (new.one, new.two, 100);
insert into view_a (one, two) values ('az','xy');
create rule view_a_r_update as on update to view_a
do instead
update a set one = new.one, two = new.two, three = new.three
where one = old.one and two = old.two;
select * from a;
update view_a set two = 'mn' where one = 'az';
select * from a;
update view_a set two = 'mo' where three = 100;
select * from a;