> The difference here is that by passing the values into a function, it
> creates a copy of the value, meaning it won't change due to an UPDATE.
> The only negative of using a function is that the number of affected
> tuples will always be zero.
The function and rule does indeed work from the psql command line. But as you mentioned, the
"UPDATE 0" makes my client frontend thinks that the update failed. So it ends up rolling the
transaction that contained the initial update statement to the view. However, the advantage with
this solution is that I know I don't get inconsistant updates, only I don't get any update
either.:-)
There is a way to get an updateable view to work just as long as I join no more than two relations
using the leaf table's ctid. This works just fine for two tables, but in my case I can have as
mean as 4 joined tables. The work around is to create a view of two tables and then recursively
join the remaining tables one at a time.
The problem here is the excessive amount of coding involved and a potential hit in preformace in
selecting from the view since the optimizer cannot use a bit-map-index scan in a multinested view.
For this reason, I don't like this solution very much.
This is a link to an email that illistrates this test case:
http://archives.postgresql.org/pgsql-general/2006-12/msg00913.php
By the way thanks for responding, very few people show interest in this topic.
Regards,
Richard Broersma Jr.
