> 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. ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
