> > > > 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. Regards Pavel > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
