Tom Lane wrote:
Now that there's a mechanism in the backend that will automatically replan queries whenever anything changes about the referenced tables, we have to worry about whether an automatic replan might cause surprising changes in the behavior of a query. I looked through the available GUC settings to see what would affect a replan, and came up with just four that would potentially affect the semantics of the query:search_path add_missing_from transform_null_equals sql_inheritance As I've already mentioned, I think we must address search_path by saving the path at time of first plan and using that same path during any replan.
Yes. I think this is the only secure way to do it.
However, I'm not excited about adding mechanism to similarly save and restore the others. They're all for legacy-app compatibility and so seem unlikely to be changed on-the-fly within a session. Also, add_missing_from and transform_null_equals aren't going to affect sanely written queries in the first place. sql_inheritance is a little bit bigger deal, but I wonder whether we shouldn't just remove that variable altogether --- it's been default ON since 7.1 and I've not heard anyone complain about that in a long time.
Let's do a quick survey on a couple mailing lists.
There are a boatload of other GUCs that could potentially result in changes of planner choices:
I think the only thing we need do about the GUCs is provide the user with a command which flushes all plans for the session. Hmmmm, that's not really necessary I suppose; one can easily reconnect.
For that matter, can anyone think why we'd need a command for the superuser to flush all plans in the server? It seems like something we ought to have, but I don't have a good case why ...
--Josh Berkus ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
