Remove the custom_variable_classes parameter.
In the upcoming PostgreSQL 9.0 merge, validating the custom variable classes was causing grief in with the new plpgsql.variable_conflict GUC. If you set that GUC after loading plpgsql in the QD, plpgsql migh still not be loaded in QE processes. If the GUC was changed in the QD, the QD would dispatch the new value to QE processes, which threw an error because the 'plpgsql' custom variable class was not defined. In principle, we would have the same problem with any other GUC added by a loadable module. To fix, cherry-pick upstream commit from 9.2, to remove the GUC and the validation of custom variable classes altogether. Might as well do that now, rather than make some temporary work-arounds, since it's a sensible change that we'll get eventually from upstream anyway. Upstream commit: commit 1a00c0ef Author: Tom Lane <tgl@sss.pgh.pa.us> Date: Tue Oct 4 12:36:18 2011 -0400 Remove the custom_variable_classes parameter. This variable provides only marginal error-prevention capability (since it can only check the prefix of a qualified GUC name), and the consensus is that that isn't worth the amount of hassle that maintaining the setting creates for DBAs. So, let's just remove it. With this commit, the system will silently accept a value for any qualified GUC name at all, whether it has anything to do with any known extension or not. (Unqualified names still have to match known built-in settings, though; and you will get a WARNING at extension load time if there's an unrecognized setting with that extension's prefix.) There's still some discussion ongoing about whether to tighten that up and if so how; but if we do come up with a solution, it's not likely to look anything like custom_variable_classes.
Showing
想要评论请 注册 或 登录