> > Hmm. I think the core problem here is that we're trying to control > the plancache, which is a pretty much behind-the-scenes mechanism. > Except in the case of an explicit PREPARE, you can't even see from > SQL that the cache is being used, or when it's used. So part of what > needs to be thought about, if we use the GUC approach, is when the > GUC's value is consulted. If we don't do anything special then > the GUC(s) would be consulted when retrieving plans from the cache, > and changes in their values from one retrieval to the next might > cause funny behavior. Maybe the relevant settings need to be captured > when the plancache entry is made ... not sure.
What sort of funny behavior are you concerned about? It seems likely to me that in most cases the GUC will have the same value every time through, but if it doesn't, I'm not sure why we'd need to use the old value rather than the current one. Indeed, if the user changes the GUC from "force custom" to "force generic" and reruns the function, we want the new value to take effect, lest a POLA violation occur.
good note - so changing this GUC on session level requires reset plan cache.
I am not against to GUC, and I am not against to PLpgSQL #option. Just, and I am repeating (I am sorry) - these tools are not practical for usage in PLpgSQL. There should be some block level possibility to do some setting.
