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



Mon, 19 Apr 2004 13:56:23 +0200
"Thomas Hallgren" <thhal@mailblocks.com>
GUC variable set, TODO

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

Mon, 19 Apr 2004 15:55:31 +0200 (CEST)
Fabien COELHO <coelho@cri.ensmp.fr>
Re: GUC variable set, TODO
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

Mon, 19 Apr 2004 11:25:08 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: GUC variable set, TODO 

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

Mon, 19 Apr 2004 17:44:38 +0200 (CEST)
Fabien COELHO <coelho@cri.ensmp.fr>
Re: GUC variable set, TODO 
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

Mon, 19 Apr 2004 12:02:45 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: GUC variable set, TODO 
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


Mon, 19 Apr 2004 19:43:57 +0200
Thomas Hallgren <thhal@mailblocks.com>
Re: GUC variable set, TODO
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,
        GucBoolAssignHook assign_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
>



Thu, 22 Apr 2004 11:24:29 +0200
"Thomas Hallgren" <thhal@mailblocks.com>
Re: GUC variable set, TODO