> ... 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
