Re: INSERT/SELECT and excessive foreign key checks

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