Dear Thomas,
> I might have some time left to spend on the item "Allow external interfaces
> to extend the GUC variable set"
> filed under "Administration" on the TODO list. I'm thinking of an approach
> with the steps:
>
> 1) Increasing my own understanding of the GUC code
Well, I did that yesterday morning;-) So I can share my little experience.
. All guc variables are described in static structures initialized at
loadtime. if it is to be extendable, it means that you have break this,
and build or add some dynamic structure(s), that will have to be
initialized somehow to be filled with current existing options.
. There are different version of these static arrays depending on the type
of the guc variable (boolean, string, integer...). The actual option
is stored in a static variable that can be set or reset with some handlers
(to check for appropriate submitted new value).
. There is also a dynamic sorted array that allows to find all variables
descriptions independently of their type, with a binary search.
. You must know that static struct variables are by default initialized to
0 in C, so if something is not initialized, its value is really 0. The
current guc code RELIES on this, for instance for "flags" initialization.
Some thoughts:
Maybe some new flags value should be added to distinguish possibly native
guc variables and others added by extensions? Also, maybe you should keep
track of the extension origin of a guc variable?
> 2) Suggest a solution on this newsgroup
> 3) Implement and submit a patch
>
> Any advice is greatly appreciated. Especially the ones that might speed up
> step #1.
>
> Comments, suggestions?
Good luck.
--
Fabien Coelho - coelho@cri.ensmp.fr
