> ... People keep proposing variants of the idea > that the executor should optimize updates on the basis of examining > the query tree to see whether columns changed or not, and they're always > wrong. You don't know what else might have been done to the row by > BEFORE triggers.
Is there a different potential hack for marking a table read-only, turning it on and off with a function()? In a hackish vein, use a trigger to enforce this, and maybe a rule that can do the optimization? I wouldn't be the one writing this, so maybe it is ridiculous and I apologize for contributing to list-noise, but perhaps it would be useful for those tables that change so rarely. Of course, it would be a "contrib" package and nothing for the core. -w ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate