Обсуждение: GUC variable set, TODO
Hi, 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 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? Regards, Thomas Hallgren
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
Fabien COELHO <coelho@cri.ensmp.fr> writes:
> . All guc variables are described in static structures initialized at
> loadtime. if it is to be extendable, it means that you have break this,
No, you don't.
> . There is also a dynamic sorted array that allows to find all variables
> descriptions independently of their type, with a binary search.
The idea was to provide an API that would allow insertion of new entries
into the dynamic array. This does not mean you have to reinvent where
the static entries come from.
regards, tom lane
Dear Tom, > > . All guc variables are described in static structures initialized at > > loadtime. if it is to be extendable, it means that you have break this, > > No, you don't. Well, sorry, I'm used to show my lack of imagination on the list;-) > > . There is also a dynamic sorted array that allows to find all variables > > descriptions independently of their type, with a binary search. > > The idea was to provide an API that would allow insertion of new entries > into the dynamic array. This does not mean you have to reinvent where > the static entries come from. Ok. I understand that you suggest to Thomas that he should only touch the search array to insert new pointers to guc description structures, which may come from outside or be newly allocated, without touching the existing static versions for internal guc variables. -- Fabien Coelho - coelho@cri.ensmp.fr
Fabien COELHO <coelho@cri.ensmp.fr> writes:
> Ok. I understand that you suggest to Thomas that he should only touch
> the search array to insert new pointers to guc description structures,
> which may come from outside or be newly allocated, without touching the
> existing static versions for internal guc variables.
Right. IIRC there are some comments about this possibility already in
the source code.
regards, tom lane
Tom Lane wrote: > Fabien COELHO <coelho@cri.ensmp.fr> writes: > >>Ok. I understand that you suggest to Thomas that he should only touch >>the search array to insert new pointers to guc description structures, >>which may come from outside or be newly allocated, without touching the >>existing static versions for internal guc variables. > > > Right. IIRC there are some comments about this possibility already in > the source code. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend > Thanks Fabien for explaing how the static stuff is built and complemented with the dynamic array. My intention is to pursue a suggestion that Tom and Joe Conway discuss in the thread that eventually ended upp in the TODO item. Here's a link to the discussion (I should of course have included this in my original post): http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php Kind Regards, Thomas Hallgren
Here's a draft of the solution that I'm currently working on for custom GUC variables: A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.c) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity and a need-sort flag is introduced to avoid resizing and resorting every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. Question: Who uses GucInfoMain and why does it call build_guc_variables() ? The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, bool* valueAddr, GucContext context, GucBoolAssignHookassign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. Comments or suggestions so far? Kind regards, Thomas Hallgren "Tom Lane" <tgl@sss.pgh.pa.us> wrote in message news:25798.1082390565@sss.pgh.pa.us... > Fabien COELHO <coelho@cri.ensmp.fr> writes: > > Ok. I understand that you suggest to Thomas that he should only touch > > the search array to insert new pointers to guc description structures, > > which may come from outside or be newly allocated, without touching the > > existing static versions for internal guc variables. > > Right. IIRC there are some comments about this possibility already in > the source code. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend >