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
