Skip site navigation (1) Skip section navigation (2)

Configuration parameters for plugin modules

From: Thomas Hallgren <thhal(at)mailblocks(dot)com>
To: pgsql-patches(at)postgresql(dot)org
Subject: Configuration parameters for plugin modules
Date: 2004-05-09 21:19:09
Message-ID: c7m78e$2b2b$1@news.hub.org (view raw or flat)
Thread:
Lists: pgsql-patches
Posted this patch 2 weeks ago. Since then new changes has been made to 
guc.c making it hard to apply. Here's a new fresh version intended for 
current cvs head.

In short:
The patch adresses the TODO list item "Allow external interfaces to 
extend the GUC variable set".

Plugin modules like the pl<lang> modules needs a way to declare 
configuration parameters. The postmaster has no knowledge of such 
modules when it reads the postgresql.conf file. Rather than allowing 
totally unknown configuration parameters, the concept of a variable 
"class" is introduced. Variables that belongs to a declared classes will 
create a placeholder value of string type and will not generate an 
error. When a module is loaded, it will declare variables for such a 
class and make those variables "consume" any placeholders that has been 
defined. Finally, the module will generate warnings for unrecognized 
placeholders defined for its class.

More detail:
The design is outlined after the suggestions made by Tom Lane and Joe 
Conway in this thread:

http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php

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.l) 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 is introduced to 
avoid resizing 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.

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,
         const char* short_desc,
         const char* long_desc,
         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. If they do, elog(INFO, ...) messages 
will be issued to inform the user that unrecognized variables are present.

Kind regards,

Thomas Hallgren

Attachment: patch.txt
Description: text/plain (23.0 KB)

Responses

pgsql-patches by date

Next:From: Andrew DunstanDate: 2004-05-10 07:17:46
Subject: Re: mingw configure failure detection
Previous:From: Andrew DunstanDate: 2004-05-09 12:16:02
Subject: Re: mingw configure failure detection

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group