On Mon, 2006-12-18 at 15:30 -0800, Richard Broersma Jr wrote: > > > postgres=# update vwife > > > set name = 'Katheryn', > > > dresssize = 12 > > > where (id,name,dresssize)=(2,'katie',11); > > > > In "UPDATE #", # is the result of the libpq function PQcmdTuples(), and > > it refers to the number of tuples affected by the last command executed. > > What's happening is that the first UPDATE in the rule changes 1 record > > in public.person, but the second update matches no rows, so that value > > is 0. > agreed. > > > That means that the WHERE clause of the second update matches nothing. > > Are you perhaps using two different id fields, and comparing against the > > wrong one? > > In this case, the id are that same since wife.id is a foreign key of person.id. The think the > problem lies in the where clause of the update statement to the update-able view. > > where (id,name,dresssize)=(2,'katie',11); > Actually, I am seeing some unexpected behavior, or rather behavior that I wouldn't expect. After the first UPDATE in the rule, NEW and OLD are gone. After reading up on the rules document, I think this is happening because the WHERE clause is applied again, and since neither NEW nor OLD satisfy the WHERE clause (because of the first UPDATE), they become non- existent. I am still a little unsure on this topic, would someone else like to comment? It seems almost like NEW and OLD act like views with the outer WHERE clause included, rather than materialized relations. The way to fix this definitively is to pass the OLD/NEW values as arguments to a function, and then they are stored as new values until the end of the function's execution, during which you can run as many UPDATEs as you want. Regards, Jeff Davis
