|
|
|
|
/*--------------------------------------------------------------------
|
|
|
|
|
* guc.h
|
|
|
|
|
*
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
3 years ago
|
|
|
* External declarations pertaining to Grand Unified Configuration.
|
|
|
|
|
*
|
|
|
|
|
* Copyright (c) 2000-2022, PostgreSQL Global Development Group
|
|
|
|
|
* Written by Peter Eisentraut <peter_e@gmx.net>.
|
|
|
|
|
*
|
|
|
|
|
* src/include/utils/guc.h
|
|
|
|
|
*--------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#ifndef GUC_H
|
|
|
|
|
#define GUC_H
|
|
|
|
|
|
|
|
|
|
#include "nodes/parsenodes.h"
|
|
|
|
|
#include "tcop/dest.h"
|
|
|
|
|
#include "utils/array.h"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* upper limit for GUC variables measured in kilobytes of memory */
|
|
|
|
|
/* note that various places assume the byte size fits in a "long" variable */
|
|
|
|
|
#if SIZEOF_SIZE_T > 4 && SIZEOF_LONG > 4
|
|
|
|
|
#define MAX_KILOBYTES INT_MAX
|
|
|
|
|
#else
|
|
|
|
|
#define MAX_KILOBYTES (INT_MAX / 1024)
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Automatic configuration file name for ALTER SYSTEM.
|
|
|
|
|
* This file will be used to store values of configuration parameters
|
|
|
|
|
* set by ALTER SYSTEM command.
|
|
|
|
|
*/
|
|
|
|
|
#define PG_AUTOCONF_FILENAME "postgresql.auto.conf"
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Certain options can only be set at certain times. The rules are
|
|
|
|
|
* like this:
|
|
|
|
|
*
|
|
|
|
|
* INTERNAL options cannot be set by the user at all, but only through
|
|
|
|
|
* internal processes ("server_version" is an example). These are GUC
|
|
|
|
|
* variables only so they can be shown by SHOW, etc.
|
|
|
|
|
*
|
|
|
|
|
* POSTMASTER options can only be set when the postmaster starts,
|
|
|
|
|
* either from the configuration file or the command line.
|
|
|
|
|
*
|
|
|
|
|
* SIGHUP options can only be set at postmaster startup or by changing
|
|
|
|
|
* the configuration file and sending the HUP signal to the postmaster
|
|
|
|
|
* or a backend process. (Notice that the signal receipt will not be
|
|
|
|
|
* evaluated immediately. The postmaster and the backend check it at a
|
|
|
|
|
* certain point in their main loop. It's safer to wait than to read a
|
|
|
|
|
* file asynchronously.)
|
|
|
|
|
*
|
|
|
|
|
* BACKEND and SU_BACKEND options can only be set at postmaster startup,
|
|
|
|
|
* from the configuration file, or by client request in the connection
|
|
|
|
|
* startup packet (e.g., from libpq's PGOPTIONS variable). SU_BACKEND
|
|
|
|
|
* options can be set from the startup packet only when the user is a
|
|
|
|
|
* superuser. Furthermore, an already-started backend will ignore changes
|
|
|
|
|
* to such an option in the configuration file. The idea is that these
|
|
|
|
|
* options are fixed for a given backend once it's started, but they can
|
|
|
|
|
* vary across backends.
|
|
|
|
|
*
|
|
|
|
|
* SUSET options can be set at postmaster startup, with the SIGHUP
|
|
|
|
|
* mechanism, or from the startup packet or SQL if you're a superuser.
|
|
|
|
|
*
|
|
|
|
|
* USERSET options can be set by anyone any time.
|
|
|
|
|
*/
|
|
|
|
|
typedef enum
|
|
|
|
|
{
|
|
|
|
|
PGC_INTERNAL,
|
|
|
|
|
PGC_POSTMASTER,
|
|
|
|
|
PGC_SIGHUP,
|
|
|
|
|
PGC_SU_BACKEND,
|
|
|
|
|
PGC_BACKEND,
|
|
|
|
|
PGC_SUSET,
|
|
|
|
|
PGC_USERSET
|
|
|
|
|
} GucContext;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The following type records the source of the current setting. A
|
|
|
|
|
* new setting can only take effect if the previous setting had the
|
|
|
|
|
* same or lower level. (E.g, changing the config file doesn't
|
|
|
|
|
* override the postmaster command line.) Tracking the source allows us
|
|
|
|
|
* to process sources in any convenient order without affecting results.
|
|
|
|
|
* Sources <= PGC_S_OVERRIDE will set the default used by RESET, as well
|
|
|
|
|
* as the current value.
|
|
|
|
|
*
|
|
|
|
|
* PGC_S_INTERACTIVE isn't actually a source value, but is the
|
|
|
|
|
* dividing line between "interactive" and "non-interactive" sources for
|
|
|
|
|
* error reporting purposes.
|
|
|
|
|
*
|
|
|
|
|
* PGC_S_TEST is used when testing values to be used later. For example,
|
|
|
|
|
* ALTER DATABASE/ROLE tests proposed per-database or per-user defaults this
|
|
|
|
|
* way, and CREATE FUNCTION tests proposed function SET clauses this way.
|
|
|
|
|
* This is an interactive case, but it needs its own source value because
|
|
|
|
|
* some assign hooks need to make different validity checks in this case.
|
|
|
|
|
* In particular, references to nonexistent database objects generally
|
|
|
|
|
* shouldn't throw hard errors in this case, at most NOTICEs, since the
|
|
|
|
|
* objects might exist by the time the setting is used for real.
|
|
|
|
|
*
|
|
|
|
|
* When setting the value of a non-compile-time-constant PGC_INTERNAL option,
|
|
|
|
|
* source == PGC_S_DYNAMIC_DEFAULT should typically be used so that the value
|
|
|
|
|
* will show as "default" in pg_settings. If there is a specific reason not
|
|
|
|
|
* to want that, use source == PGC_S_OVERRIDE.
|
|
|
|
|
*
|
|
|
|
|
* NB: see GucSource_Names in guc.c if you change this.
|
|
|
|
|
*/
|
|
|
|
|
typedef enum
|
|
|
|
|
{
|
Split PGC_S_DEFAULT into two values, for true boot_val vs computed default.
Failure to distinguish these cases is the real cause behind the recent
reports of Windows builds crashing on 'infinity'::timestamp, which was
directly due to failure to establish a value of timezone_abbreviations
in postmaster child processes. The postmaster had the desired value,
but write_one_nondefault_variable() didn't transmit it to backends.
To fix that, invent a new value PGC_S_DYNAMIC_DEFAULT, and be sure to use
that or PGC_S_ENV_VAR (as appropriate) for "default" settings that are
computed during initialization. (We need both because there's at least
one variable that could receive a value from either source.)
This commit also fixes ProcessConfigFile's failure to restore the correct
default value for certain GUC variables if they are set in postgresql.conf
and then removed/commented out of the file. We have to recompute and
reinstall the value for any GUC variable that could have received a value
from PGC_S_DYNAMIC_DEFAULT or PGC_S_ENV_VAR sources, and there were a
number of oversights. (That whole thing is a crock that needs to be
redesigned, but not today.)
However, I intentionally didn't make it work "exactly right" for the cases
of timezone and log_timezone. The exactly right behavior would involve
running select_default_timezone, which we'd have to do independently in
each postgres process, causing the whole database to become entirely
unresponsive for as much as several seconds. That didn't seem like a good
idea, especially since the variable's removal from postgresql.conf might be
just an accidental edit. Instead the behavior is to adopt the previously
active setting as if it were default.
Note that this patch creates an ABI break for extensions that use any of
the PGC_S_XXX constants; they'll need to be recompiled.
15 years ago
|
|
|
PGC_S_DEFAULT, /* hard-wired default ("boot_val") */
|
|
|
|
|
PGC_S_DYNAMIC_DEFAULT, /* default computed during initialization */
|
|
|
|
|
PGC_S_ENV_VAR, /* postmaster environment variable */
|
|
|
|
|
PGC_S_FILE, /* postgresql.conf */
|
|
|
|
|
PGC_S_ARGV, /* postmaster command line */
|
|
|
|
|
PGC_S_GLOBAL, /* global in-database setting */
|
|
|
|
|
PGC_S_DATABASE, /* per-database setting */
|
|
|
|
|
PGC_S_USER, /* per-user setting */
|
|
|
|
|
PGC_S_DATABASE_USER, /* per-user-and-database setting */
|
|
|
|
|
PGC_S_CLIENT, /* from client connection request */
|
|
|
|
|
PGC_S_OVERRIDE, /* special case to forcibly set default */
|
|
|
|
|
PGC_S_INTERACTIVE, /* dividing line for error reporting */
|
|
|
|
|
PGC_S_TEST, /* test per-database or per-user setting */
|
|
|
|
|
PGC_S_SESSION /* SET command */
|
|
|
|
|
} GucSource;
|
|
|
|
|
|
|
|
|
|
/*
|
Improve design and implementation of pg_file_settings view.
As first committed, this view reported on the file contents as they were
at the last SIGHUP event. That's not as useful as reporting on the current
contents, and what's more, it didn't work right on Windows unless the
current session had serviced at least one SIGHUP. Therefore, arrange to
re-read the files when pg_show_all_settings() is called. This requires
only minor refactoring so that we can pass changeVal = false to
set_config_option() so that it won't actually apply any changes locally.
In addition, add error reporting so that errors that would prevent the
configuration files from being loaded, or would prevent individual settings
from being applied, are visible directly in the view. This makes the view
usable for pre-testing whether edits made in the config files will have the
desired effect, before one actually issues a SIGHUP.
I also added an "applied" column so that it's easy to identify entries that
are superseded by later entries; this was the main use-case for the original
design, but it seemed unnecessarily hard to use for that.
Also fix a 9.4.1 regression that allowed multiple entries for a
PGC_POSTMASTER variable to cause bogus complaints in the postmaster log.
(The issue here was that commit bf007a27acd7b2fb unintentionally reverted
3e3f65973a3c94a6, which suppressed any duplicate entries within
ParseConfigFp. However, since the original coding of the pg_file_settings
view depended on such suppression *not* happening, we couldn't have fixed
this issue now without first doing something with pg_file_settings.
Now we suppress duplicates by marking them "ignored" within
ProcessConfigFileInternal, which doesn't hide them in the view.)
Lesser changes include:
Drive the view directly off the ConfigVariable list, instead of making a
basically-equivalent second copy of the data. There's no longer any need
to hang onto the data permanently, anyway.
Convert show_all_file_settings() to do its work in one call and return a
tuplestore; this avoids risks associated with assuming that the GUC state
will hold still over the course of query execution. (I think there were
probably latent bugs here, though you might need something like a cursor
on the view to expose them.)
Arrange to run SIGHUP processing in a short-lived memory context, to
forestall process-lifespan memory leaks. (There is one known leak in this
code, in ProcessConfigDirectory; it seems minor enough to not be worth
back-patching a specific fix for.)
Remove mistaken assignment to ConfigFileLineno that caused line counting
after an include_dir directive to be completely wrong.
Add missed failure check in AlterSystemSetConfigFile(). We don't really
expect ParseConfigFp() to fail, but that's not an excuse for not checking.
10 years ago
|
|
|
* Parsing the configuration file(s) will return a list of name-value pairs
|
|
|
|
|
* with source location info. We also abuse this data structure to carry
|
|
|
|
|
* error reports about the config files. An entry reporting an error will
|
|
|
|
|
* have errmsg != NULL, and might have NULLs for name, value, and/or filename.
|
|
|
|
|
*
|
|
|
|
|
* If "ignore" is true, don't attempt to apply the item (it might be an error
|
|
|
|
|
* report, or an item we determined to be duplicate). "applied" is set true
|
|
|
|
|
* if we successfully applied, or could have applied, the setting.
|
|
|
|
|
*/
|
|
|
|
|
typedef struct ConfigVariable
|
|
|
|
|
{
|
|
|
|
|
char *name;
|
|
|
|
|
char *value;
|
Improve design and implementation of pg_file_settings view.
As first committed, this view reported on the file contents as they were
at the last SIGHUP event. That's not as useful as reporting on the current
contents, and what's more, it didn't work right on Windows unless the
current session had serviced at least one SIGHUP. Therefore, arrange to
re-read the files when pg_show_all_settings() is called. This requires
only minor refactoring so that we can pass changeVal = false to
set_config_option() so that it won't actually apply any changes locally.
In addition, add error reporting so that errors that would prevent the
configuration files from being loaded, or would prevent individual settings
from being applied, are visible directly in the view. This makes the view
usable for pre-testing whether edits made in the config files will have the
desired effect, before one actually issues a SIGHUP.
I also added an "applied" column so that it's easy to identify entries that
are superseded by later entries; this was the main use-case for the original
design, but it seemed unnecessarily hard to use for that.
Also fix a 9.4.1 regression that allowed multiple entries for a
PGC_POSTMASTER variable to cause bogus complaints in the postmaster log.
(The issue here was that commit bf007a27acd7b2fb unintentionally reverted
3e3f65973a3c94a6, which suppressed any duplicate entries within
ParseConfigFp. However, since the original coding of the pg_file_settings
view depended on such suppression *not* happening, we couldn't have fixed
this issue now without first doing something with pg_file_settings.
Now we suppress duplicates by marking them "ignored" within
ProcessConfigFileInternal, which doesn't hide them in the view.)
Lesser changes include:
Drive the view directly off the ConfigVariable list, instead of making a
basically-equivalent second copy of the data. There's no longer any need
to hang onto the data permanently, anyway.
Convert show_all_file_settings() to do its work in one call and return a
tuplestore; this avoids risks associated with assuming that the GUC state
will hold still over the course of query execution. (I think there were
probably latent bugs here, though you might need something like a cursor
on the view to expose them.)
Arrange to run SIGHUP processing in a short-lived memory context, to
forestall process-lifespan memory leaks. (There is one known leak in this
code, in ProcessConfigDirectory; it seems minor enough to not be worth
back-patching a specific fix for.)
Remove mistaken assignment to ConfigFileLineno that caused line counting
after an include_dir directive to be completely wrong.
Add missed failure check in AlterSystemSetConfigFile(). We don't really
expect ParseConfigFp() to fail, but that's not an excuse for not checking.
10 years ago
|
|
|
char *errmsg;
|
|
|
|
|
char *filename;
|
|
|
|
|
int sourceline;
|
Improve design and implementation of pg_file_settings view.
As first committed, this view reported on the file contents as they were
at the last SIGHUP event. That's not as useful as reporting on the current
contents, and what's more, it didn't work right on Windows unless the
current session had serviced at least one SIGHUP. Therefore, arrange to
re-read the files when pg_show_all_settings() is called. This requires
only minor refactoring so that we can pass changeVal = false to
set_config_option() so that it won't actually apply any changes locally.
In addition, add error reporting so that errors that would prevent the
configuration files from being loaded, or would prevent individual settings
from being applied, are visible directly in the view. This makes the view
usable for pre-testing whether edits made in the config files will have the
desired effect, before one actually issues a SIGHUP.
I also added an "applied" column so that it's easy to identify entries that
are superseded by later entries; this was the main use-case for the original
design, but it seemed unnecessarily hard to use for that.
Also fix a 9.4.1 regression that allowed multiple entries for a
PGC_POSTMASTER variable to cause bogus complaints in the postmaster log.
(The issue here was that commit bf007a27acd7b2fb unintentionally reverted
3e3f65973a3c94a6, which suppressed any duplicate entries within
ParseConfigFp. However, since the original coding of the pg_file_settings
view depended on such suppression *not* happening, we couldn't have fixed
this issue now without first doing something with pg_file_settings.
Now we suppress duplicates by marking them "ignored" within
ProcessConfigFileInternal, which doesn't hide them in the view.)
Lesser changes include:
Drive the view directly off the ConfigVariable list, instead of making a
basically-equivalent second copy of the data. There's no longer any need
to hang onto the data permanently, anyway.
Convert show_all_file_settings() to do its work in one call and return a
tuplestore; this avoids risks associated with assuming that the GUC state
will hold still over the course of query execution. (I think there were
probably latent bugs here, though you might need something like a cursor
on the view to expose them.)
Arrange to run SIGHUP processing in a short-lived memory context, to
forestall process-lifespan memory leaks. (There is one known leak in this
code, in ProcessConfigDirectory; it seems minor enough to not be worth
back-patching a specific fix for.)
Remove mistaken assignment to ConfigFileLineno that caused line counting
after an include_dir directive to be completely wrong.
Add missed failure check in AlterSystemSetConfigFile(). We don't really
expect ParseConfigFp() to fail, but that's not an excuse for not checking.
10 years ago
|
|
|
bool ignore;
|
|
|
|
|
bool applied;
|
|
|
|
|
struct ConfigVariable *next;
|
|
|
|
|
} ConfigVariable;
|
|
|
|
|
|
Improve design and implementation of pg_file_settings view.
As first committed, this view reported on the file contents as they were
at the last SIGHUP event. That's not as useful as reporting on the current
contents, and what's more, it didn't work right on Windows unless the
current session had serviced at least one SIGHUP. Therefore, arrange to
re-read the files when pg_show_all_settings() is called. This requires
only minor refactoring so that we can pass changeVal = false to
set_config_option() so that it won't actually apply any changes locally.
In addition, add error reporting so that errors that would prevent the
configuration files from being loaded, or would prevent individual settings
from being applied, are visible directly in the view. This makes the view
usable for pre-testing whether edits made in the config files will have the
desired effect, before one actually issues a SIGHUP.
I also added an "applied" column so that it's easy to identify entries that
are superseded by later entries; this was the main use-case for the original
design, but it seemed unnecessarily hard to use for that.
Also fix a 9.4.1 regression that allowed multiple entries for a
PGC_POSTMASTER variable to cause bogus complaints in the postmaster log.
(The issue here was that commit bf007a27acd7b2fb unintentionally reverted
3e3f65973a3c94a6, which suppressed any duplicate entries within
ParseConfigFp. However, since the original coding of the pg_file_settings
view depended on such suppression *not* happening, we couldn't have fixed
this issue now without first doing something with pg_file_settings.
Now we suppress duplicates by marking them "ignored" within
ProcessConfigFileInternal, which doesn't hide them in the view.)
Lesser changes include:
Drive the view directly off the ConfigVariable list, instead of making a
basically-equivalent second copy of the data. There's no longer any need
to hang onto the data permanently, anyway.
Convert show_all_file_settings() to do its work in one call and return a
tuplestore; this avoids risks associated with assuming that the GUC state
will hold still over the course of query execution. (I think there were
probably latent bugs here, though you might need something like a cursor
on the view to expose them.)
Arrange to run SIGHUP processing in a short-lived memory context, to
forestall process-lifespan memory leaks. (There is one known leak in this
code, in ProcessConfigDirectory; it seems minor enough to not be worth
back-patching a specific fix for.)
Remove mistaken assignment to ConfigFileLineno that caused line counting
after an include_dir directive to be completely wrong.
Add missed failure check in AlterSystemSetConfigFile(). We don't really
expect ParseConfigFp() to fail, but that's not an excuse for not checking.
10 years ago
|
|
|
extern bool ParseConfigFile(const char *config_file, bool strict,
|
|
|
|
|
const char *calling_file, int calling_lineno,
|
|
|
|
|
int depth, int elevel,
|
|
|
|
|
ConfigVariable **head_p, ConfigVariable **tail_p);
|
|
|
|
|
extern bool ParseConfigFp(FILE *fp, const char *config_file,
|
|
|
|
|
int depth, int elevel,
|
|
|
|
|
ConfigVariable **head_p, ConfigVariable **tail_p);
|
|
|
|
|
extern bool ParseConfigDirectory(const char *includedir,
|
|
|
|
|
const char *calling_file, int calling_lineno,
|
|
|
|
|
int depth, int elevel,
|
|
|
|
|
ConfigVariable **head_p,
|
|
|
|
|
ConfigVariable **tail_p);
|
|
|
|
|
extern void FreeConfigVariables(ConfigVariable *list);
|
|
|
|
|
extern char *DeescapeQuotedString(const char *s);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The possible values of an enum variable are specified by an array of
|
|
|
|
|
* name-value pairs. The "hidden" flag means the value is accepted but
|
|
|
|
|
* won't be displayed when guc.c is asked for a list of acceptable values.
|
|
|
|
|
*/
|
|
|
|
|
struct config_enum_entry
|
|
|
|
|
{
|
|
|
|
|
const char *name;
|
|
|
|
|
int val;
|
|
|
|
|
bool hidden;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Signatures for per-variable check/assign/show hook functions
|
|
|
|
|
*/
|
|
|
|
|
typedef bool (*GucBoolCheckHook) (bool *newval, void **extra, GucSource source);
|
|
|
|
|
typedef bool (*GucIntCheckHook) (int *newval, void **extra, GucSource source);
|
|
|
|
|
typedef bool (*GucRealCheckHook) (double *newval, void **extra, GucSource source);
|
|
|
|
|
typedef bool (*GucStringCheckHook) (char **newval, void **extra, GucSource source);
|
|
|
|
|
typedef bool (*GucEnumCheckHook) (int *newval, void **extra, GucSource source);
|
|
|
|
|
|
|
|
|
|
typedef void (*GucBoolAssignHook) (bool newval, void *extra);
|
|
|
|
|
typedef void (*GucIntAssignHook) (int newval, void *extra);
|
|
|
|
|
typedef void (*GucRealAssignHook) (double newval, void *extra);
|
|
|
|
|
typedef void (*GucStringAssignHook) (const char *newval, void *extra);
|
|
|
|
|
typedef void (*GucEnumAssignHook) (int newval, void *extra);
|
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.
Thomas Hallgren
22 years ago
|
|
|
|
|
|
|
|
typedef const char *(*GucShowHook) (void);
|
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.
Thomas Hallgren
22 years ago
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Miscellaneous
|
|
|
|
|
*/
|
|
|
|
|
typedef enum
|
|
|
|
|
{
|
|
|
|
|
/* Types of set_config_option actions */
|
|
|
|
|
GUC_ACTION_SET, /* regular SET command */
|
|
|
|
|
GUC_ACTION_LOCAL, /* SET LOCAL command */
|
Improve and simplify CREATE EXTENSION's management of GUC variables.
CREATE EXTENSION needs to transiently set search_path, as well as
client_min_messages and log_min_messages. We were doing this by the
expedient of saving the current string value of each variable, doing a
SET LOCAL, and then doing another SET LOCAL with the previous value at
the end of the command. This is a bit expensive though, and it also fails
badly if there is anything funny about the existing search_path value,
as seen in a recent report from Roger Niederland. Fortunately, there's a
much better way, which is to piggyback on the GUC infrastructure previously
developed for functions with SET options. We just open a new GUC nesting
level, do our assignments with GUC_ACTION_SAVE, and then close the nesting
level when done. This automatically restores the prior settings without a
re-parsing pass, so (in principle anyway) there can't be an error. And
guc.c still takes care of cleanup in event of an error abort.
The CREATE EXTENSION code for this was modeled on some much older code in
ri_triggers.c, which I also changed to use the better method, even though
there wasn't really much risk of failure there. Also improve the comments
in guc.c to reflect this additional usage.
14 years ago
|
|
|
GUC_ACTION_SAVE /* function SET option, or temp assignment */
|
|
|
|
|
} GucAction;
|
|
|
|
|
|
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.
Thomas Hallgren
22 years ago
|
|
|
#define GUC_QUALIFIER_SEPARATOR '.'
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* bit values in "flags" of a GUC variable
|
|
|
|
|
*/
|
|
|
|
|
#define GUC_LIST_INPUT 0x0001 /* input can be list format */
|
|
|
|
|
#define GUC_LIST_QUOTE 0x0002 /* double-quote list elements */
|
|
|
|
|
#define GUC_NO_SHOW_ALL 0x0004 /* exclude from SHOW ALL */
|
Introduce GUC_NO_RESET flag.
Previously, the transaction-property GUCs such as transaction_isolation
could be reset after starting a transaction, because we marked them
as GUC_NO_RESET_ALL but still allowed a targeted RESET. That leads to
assertion failures or worse, because those properties aren't supposed
to change after we've acquired a transaction snapshot.
There are some NO_RESET_ALL variables for which RESET is okay, so
we can't just redefine the semantics of that flag. Instead introduce
a separate GUC_NO_RESET flag. Mark "seed", as well as the transaction
property GUCs, as GUC_NO_RESET.
We have to disallow GUC_ACTION_SAVE as well as straight RESET, because
otherwise a function having a "SET transaction_isolation" clause can
still break things: the end-of-function restore action is equivalent
to a RESET.
No back-patch, as it's conceivable that someone is doing something
this patch will forbid (like resetting one of these GUCs at transaction
start, or "CREATE FUNCTION ... SET transaction_read_only = 1") and not
running into problems with it today. Given how long we've had this
issue and not noticed, the side effects in non-assert builds can't be
too serious.
Per bug #17385 from Andrew Bille.
Masahiko Sawada
Discussion: https://postgr.es/m/17385-9ee529fb091f0ce5@postgresql.org
3 years ago
|
|
|
#define GUC_NO_RESET 0x400000 /* disallow RESET and SAVE */
|
|
|
|
|
#define GUC_NO_RESET_ALL 0x0008 /* exclude from RESET ALL */
|
|
|
|
|
#define GUC_REPORT 0x0010 /* auto-report changes to client */
|
|
|
|
|
#define GUC_NOT_IN_SAMPLE 0x0020 /* not in postgresql.conf.sample */
|
|
|
|
|
#define GUC_DISALLOW_IN_FILE 0x0040 /* can't set in postgresql.conf */
|
|
|
|
|
#define GUC_CUSTOM_PLACEHOLDER 0x0080 /* placeholder for custom variable */
|
|
|
|
|
#define GUC_SUPERUSER_ONLY 0x0100 /* show only to superusers */
|
|
|
|
|
#define GUC_IS_NAME 0x0200 /* limit string to NAMEDATALEN-1 */
|
|
|
|
|
#define GUC_NOT_WHILE_SEC_REST 0x0400 /* can't set if security restricted */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
8 years ago
|
|
|
#define GUC_DISALLOW_IN_AUTO_FILE 0x0800 /* can't set in
|
|
|
|
|
* PG_AUTOCONF_FILENAME */
|
|
|
|
|
|
|
|
|
|
#define GUC_UNIT_KB 0x1000 /* value is in kilobytes */
|
|
|
|
|
#define GUC_UNIT_BLOCKS 0x2000 /* value is in blocks */
|
|
|
|
|
#define GUC_UNIT_XBLOCKS 0x3000 /* value is in xlog blocks */
|
|
|
|
|
#define GUC_UNIT_MB 0x4000 /* value is in megabytes */
|
|
|
|
|
#define GUC_UNIT_BYTE 0x5000 /* value is in bytes */
|
|
|
|
|
#define GUC_UNIT_MEMORY 0xF000 /* mask for size-related units */
|
|
|
|
|
|
|
|
|
|
#define GUC_UNIT_MS 0x10000 /* value is in milliseconds */
|
|
|
|
|
#define GUC_UNIT_S 0x20000 /* value is in seconds */
|
|
|
|
|
#define GUC_UNIT_MIN 0x30000 /* value is in minutes */
|
|
|
|
|
#define GUC_UNIT_TIME 0xF0000 /* mask for time-related units */
|
|
|
|
|
|
|
|
|
|
#define GUC_EXPLAIN 0x100000 /* include in explain */
|
|
|
|
|
|
Support "postgres -C" with runtime-computed GUCs
Until now, the -C option of postgres was handled before a small subset
of GUCs computed at runtime are initialized, leading to incorrect
results as GUC machinery would fall back to default values for such
parameters.
For example, data_checksums could report "off" for a cluster as the
control file is not loaded yet. Or wal_segment_size would show a
segment size at 16MB even if initdb --wal-segsize used something else.
Worse, the command would fail to properly report the recently-introduced
shared_memory, that requires to load shared_preload_libraries as these
could ask for a chunk of shared memory.
Support for runtime GUCs comes with a limitation, as the operation is
now allowed on a running server. One notable reason for this is that
_PG_init() functions of loadable libraries are called before all
runtime-computed GUCs are initialized, and this is not guaranteed to be
safe to do on running servers. For the case of shared_memory_size,
where we want to know how much memory would be used without allocating
it, this limitation is fine. Another case where this will help is for
huge pages, with the introduction of a different GUC to evaluate the
amount of huge pages required for a server before starting it, without
having to allocate large chunks of memory.
This feature is controlled with a new GUC flag, and four parameters are
classified as runtime-computed as of this change:
- data_checksums
- shared_memory_size
- data_directory_mode
- wal_segment_size
Some TAP tests are added to provide some coverage here, using
data_checksums in the tests of pg_checksums.
Per discussion with Andres Freund, Justin Pryzby, Magnus Hagander and
more.
Author: Nathan Bossart
Discussion: https://postgr.es/m/F2772387-CE0F-46BF-B5F1-CC55516EB885@amazon.com
4 years ago
|
|
|
/*
|
|
|
|
|
* GUC_RUNTIME_COMPUTED is intended for runtime-computed GUCs that are only
|
|
|
|
|
* available via 'postgres -C' if the server is not running.
|
|
|
|
|
*/
|
|
|
|
|
#define GUC_RUNTIME_COMPUTED 0x200000
|
|
|
|
|
|
|
|
|
|
#define GUC_UNIT (GUC_UNIT_MEMORY | GUC_UNIT_TIME)
|
|
|
|
|
|
|
|
|
|
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
3 years ago
|
|
|
/* GUC vars that are actually defined in guc_tables.c, rather than elsewhere */
|
|
|
|
|
extern PGDLLIMPORT bool Debug_print_plan;
|
|
|
|
|
extern PGDLLIMPORT bool Debug_print_parse;
|
|
|
|
|
extern PGDLLIMPORT bool Debug_print_rewritten;
|
|
|
|
|
extern PGDLLIMPORT bool Debug_pretty_print;
|
|
|
|
|
|
|
|
|
|
extern PGDLLIMPORT bool log_parser_stats;
|
|
|
|
|
extern PGDLLIMPORT bool log_planner_stats;
|
|
|
|
|
extern PGDLLIMPORT bool log_executor_stats;
|
|
|
|
|
extern PGDLLIMPORT bool log_statement_stats;
|
|
|
|
|
extern PGDLLIMPORT bool log_btree_build_stats;
|
|
|
|
|
|
|
|
|
|
extern PGDLLIMPORT bool check_function_bodies;
|
|
|
|
|
extern PGDLLIMPORT bool session_auth_is_superuser;
|
|
|
|
|
|
|
|
|
|
extern PGDLLIMPORT bool log_duration;
|
|
|
|
|
extern PGDLLIMPORT int log_parameter_max_length;
|
|
|
|
|
extern PGDLLIMPORT int log_parameter_max_length_on_error;
|
|
|
|
|
extern PGDLLIMPORT int log_min_error_statement;
|
|
|
|
|
extern PGDLLIMPORT int log_min_messages;
|
|
|
|
|
extern PGDLLIMPORT int client_min_messages;
|
|
|
|
|
extern PGDLLIMPORT int log_min_duration_sample;
|
|
|
|
|
extern PGDLLIMPORT int log_min_duration_statement;
|
|
|
|
|
extern PGDLLIMPORT int log_temp_files;
|
|
|
|
|
extern PGDLLIMPORT double log_statement_sample_rate;
|
|
|
|
|
extern PGDLLIMPORT double log_xact_sample_rate;
|
|
|
|
|
extern PGDLLIMPORT char *backtrace_functions;
|
|
|
|
|
|
|
|
|
|
extern PGDLLIMPORT int temp_file_limit;
|
|
|
|
|
|
|
|
|
|
extern PGDLLIMPORT int num_temp_buffers;
|
|
|
|
|
|
|
|
|
|
extern PGDLLIMPORT char *cluster_name;
|
|
|
|
|
extern PGDLLIMPORT char *ConfigFileName;
|
|
|
|
|
extern PGDLLIMPORT char *HbaFileName;
|
|
|
|
|
extern PGDLLIMPORT char *IdentFileName;
|
|
|
|
|
extern PGDLLIMPORT char *external_pid_file;
|
|
|
|
|
|
|
|
|
|
extern PGDLLIMPORT char *application_name;
|
|
|
|
|
|
|
|
|
|
extern PGDLLIMPORT int tcp_keepalives_idle;
|
|
|
|
|
extern PGDLLIMPORT int tcp_keepalives_interval;
|
|
|
|
|
extern PGDLLIMPORT int tcp_keepalives_count;
|
|
|
|
|
extern PGDLLIMPORT int tcp_user_timeout;
|
|
|
|
|
|
|
|
|
|
#ifdef TRACE_SORT
|
|
|
|
|
extern PGDLLIMPORT bool trace_sort;
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Functions exported by guc.c
|
|
|
|
|
*/
|
|
|
|
|
extern void SetConfigOption(const char *name, const char *value,
|
|
|
|
|
GucContext context, GucSource source);
|
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.
Thomas Hallgren
22 years ago
|
|
|
|
|
|
|
|
extern void DefineCustomBoolVariable(const char *name,
|
|
|
|
|
const char *short_desc,
|
|
|
|
|
const char *long_desc,
|
|
|
|
|
bool *valueAddr,
|
|
|
|
|
bool bootValue,
|
|
|
|
|
GucContext context,
|
|
|
|
|
int flags,
|
|
|
|
|
GucBoolCheckHook check_hook,
|
|
|
|
|
GucBoolAssignHook assign_hook,
|
|
|
|
|
GucShowHook show_hook) pg_attribute_nonnull(1, 4);
|
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.
Thomas Hallgren
22 years ago
|
|
|
|
|
|
|
|
extern void DefineCustomIntVariable(const char *name,
|
|
|
|
|
const char *short_desc,
|
|
|
|
|
const char *long_desc,
|
|
|
|
|
int *valueAddr,
|
|
|
|
|
int bootValue,
|
|
|
|
|
int minValue,
|
|
|
|
|
int maxValue,
|
|
|
|
|
GucContext context,
|
|
|
|
|
int flags,
|
|
|
|
|
GucIntCheckHook check_hook,
|
|
|
|
|
GucIntAssignHook assign_hook,
|
|
|
|
|
GucShowHook show_hook) pg_attribute_nonnull(1, 4);
|
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.
Thomas Hallgren
22 years ago
|
|
|
|
|
|
|
|
extern void DefineCustomRealVariable(const char *name,
|
|
|
|
|
const char *short_desc,
|
|
|
|
|
const char *long_desc,
|
|
|
|
|
double *valueAddr,
|
|
|
|
|
double bootValue,
|
|
|
|
|
double minValue,
|
|
|
|
|
double maxValue,
|
|
|
|
|
GucContext context,
|
|
|
|
|
int flags,
|
|
|
|
|
GucRealCheckHook check_hook,
|
|
|
|
|
GucRealAssignHook assign_hook,
|
|
|
|
|
GucShowHook show_hook) pg_attribute_nonnull(1, 4);
|
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.
Thomas Hallgren
22 years ago
|
|
|
|
|
|
|
|
extern void DefineCustomStringVariable(const char *name,
|
|
|
|
|
const char *short_desc,
|
|
|
|
|
const char *long_desc,
|
|
|
|
|
char **valueAddr,
|
|
|
|
|
const char *bootValue,
|
|
|
|
|
GucContext context,
|
|
|
|
|
int flags,
|
|
|
|
|
GucStringCheckHook check_hook,
|
|
|
|
|
GucStringAssignHook assign_hook,
|
|
|
|
|
GucShowHook show_hook) pg_attribute_nonnull(1, 4);
|
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.
Thomas Hallgren
22 years ago
|
|
|
|
|
|
|
|
extern void DefineCustomEnumVariable(const char *name,
|
|
|
|
|
const char *short_desc,
|
|
|
|
|
const char *long_desc,
|
|
|
|
|
int *valueAddr,
|
|
|
|
|
int bootValue,
|
|
|
|
|
const struct config_enum_entry *options,
|
|
|
|
|
GucContext context,
|
|
|
|
|
int flags,
|
|
|
|
|
GucEnumCheckHook check_hook,
|
|
|
|
|
GucEnumAssignHook assign_hook,
|
|
|
|
|
GucShowHook show_hook) pg_attribute_nonnull(1, 4);
|
|
|
|
|
|
|
|
|
|
extern void MarkGUCPrefixReserved(const char *className);
|
|
|
|
|
|
|
|
|
|
/* old name for MarkGUCPrefixReserved, for backwards compatibility: */
|
|
|
|
|
#define EmitWarningsOnPlaceholders(className) MarkGUCPrefixReserved(className)
|
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.
Thomas Hallgren
22 years ago
|
|
|
|
|
|
|
|
extern const char *GetConfigOption(const char *name, bool missing_ok,
|
|
|
|
|
bool restrict_privileged);
|
|
|
|
|
extern const char *GetConfigOptionResetString(const char *name);
|
Fix mishandling of quoted-list GUC values in pg_dump and ruleutils.c.
Code that prints out the contents of setconfig or proconfig arrays in
SQL format needs to handle GUC_LIST_QUOTE variables differently from
other ones, because for those variables, flatten_set_variable_args()
already applied a layer of quoting. The value can therefore safely
be printed as-is, and indeed must be, or flatten_set_variable_args()
will muck it up completely on reload. For all other GUC variables,
it's necessary and sufficient to quote the value as a SQL literal.
We'd recognized the need for this long ago, but mis-analyzed the
need slightly, thinking that all GUC_LIST_INPUT variables needed
the special treatment. That's actually wrong, since a valid value
of a LIST variable might include characters that need quoting,
although no existing variables accept such values.
More to the point, we hadn't made any particular effort to keep the
various places that deal with this up-to-date with the set of variables
that actually need special treatment, meaning that we'd do the wrong
thing with, for example, temp_tablespaces values. This affects dumping
of SET clauses attached to functions, as well as ALTER DATABASE/ROLE SET
commands.
In ruleutils.c we can fix it reasonably honestly by exporting a guc.c
function that allows discovering the flags for a given GUC variable.
But pg_dump doesn't have easy access to that, so continue the old method
of having a hard-wired list of affected variable names. At least we can
fix it to have just one list not two, and update the list to match
current reality.
A remaining problem with this is that it only works for built-in
GUC variables. pg_dump's list obvious knows nothing of third-party
extensions, and even the "ask guc.c" method isn't bulletproof since
the relevant extension might not be loaded. There's no obvious
solution to that, so for now, we'll just have to discourage extension
authors from inventing custom GUCs that need GUC_LIST_QUOTE.
This has been busted for a long time, so back-patch to all supported
branches.
Michael Paquier and Tom Lane, reviewed by Kyotaro Horiguchi and
Pavel Stehule
Discussion: https://postgr.es/m/20180111064900.GA51030@paquier.xyz
8 years ago
|
|
|
extern int GetConfigOptionFlags(const char *name, bool missing_ok);
|
|
|
|
|
extern void ProcessConfigFile(GucContext context);
|
|
|
|
|
extern char *convert_GUC_name_for_parameter_acl(const char *name);
|
|
|
|
|
extern bool check_GUC_name_for_parameter_acl(const char *name);
|
|
|
|
|
extern void InitializeGUCOptions(void);
|
|
|
|
|
extern bool SelectConfigFiles(const char *userDoption, const char *progname);
|
|
|
|
|
extern void ResetAllOptions(void);
|
|
|
|
|
extern void AtStart_GUC(void);
|
|
|
|
|
extern int NewGUCNestLevel(void);
|
|
|
|
|
extern void AtEOXact_GUC(bool isCommit, int nestLevel);
|
|
|
|
|
extern void BeginReportingGUCOptions(void);
|
|
|
|
|
extern void ReportChangedGUCOptions(void);
|
|
|
|
|
extern void ParseLongOption(const char *string, char **name, char **value);
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
3 years ago
|
|
|
extern const char *get_config_unit_name(int flags);
|
|
|
|
|
extern bool parse_int(const char *value, int *result, int flags,
|
|
|
|
|
const char **hintmsg);
|
|
|
|
|
extern bool parse_real(const char *value, double *result, int flags,
|
|
|
|
|
const char **hintmsg);
|
|
|
|
|
extern int set_config_option(const char *name, const char *value,
|
|
|
|
|
GucContext context, GucSource source,
|
|
|
|
|
GucAction action, bool changeVal, int elevel,
|
|
|
|
|
bool is_reload);
|
|
|
|
|
extern int set_config_option_ext(const char *name, const char *value,
|
|
|
|
|
GucContext context, GucSource source,
|
|
|
|
|
Oid srole,
|
|
|
|
|
GucAction action, bool changeVal, int elevel,
|
|
|
|
|
bool is_reload);
|
|
|
|
|
extern void AlterSystemSetConfigFile(AlterSystemStmt *altersysstmt);
|
|
|
|
|
extern char *GetConfigOptionByName(const char *name, const char **varname,
|
|
|
|
|
bool missing_ok);
|
|
|
|
|
extern int GetNumConfigOptions(void);
|
|
|
|
|
|
|
|
|
|
extern void ProcessGUCArray(ArrayType *array,
|
|
|
|
|
GucContext context, GucSource source, GucAction action);
|
|
|
|
|
extern ArrayType *GUCArrayAdd(ArrayType *array, const char *name, const char *value);
|
|
|
|
|
extern ArrayType *GUCArrayDelete(ArrayType *array, const char *name);
|
|
|
|
|
extern ArrayType *GUCArrayReset(ArrayType *array);
|
|
|
|
|
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
3 years ago
|
|
|
extern void *guc_malloc(int elevel, size_t size);
|
|
|
|
|
extern pg_nodiscard void *guc_realloc(int elevel, void *old, size_t size);
|
|
|
|
|
extern char *guc_strdup(int elevel, const char *src);
|
|
|
|
|
|
|
|
|
|
#ifdef EXEC_BACKEND
|
|
|
|
|
extern void write_nondefault_variables(GucContext context);
|
|
|
|
|
extern void read_nondefault_variables(void);
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* GUC serialization */
|
|
|
|
|
extern Size EstimateGUCStateSpace(void);
|
|
|
|
|
extern void SerializeGUCState(Size maxsize, char *start_address);
|
|
|
|
|
extern void RestoreGUCState(void *gucstate);
|
|
|
|
|
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
3 years ago
|
|
|
/* Functions exported by guc_funcs.c */
|
|
|
|
|
extern void ExecSetVariableStmt(VariableSetStmt *stmt, bool isTopLevel);
|
|
|
|
|
extern char *ExtractSetVariableArgs(VariableSetStmt *stmt);
|
|
|
|
|
extern void SetPGVariable(const char *name, List *args, bool is_local);
|
|
|
|
|
extern void GetPGVariable(const char *name, DestReceiver *dest);
|
|
|
|
|
extern TupleDesc GetPGVariableResultDesc(const char *name);
|
|
|
|
|
|
|
|
|
|
/* Support for messages reported from GUC check hooks */
|
|
|
|
|
|
|
|
|
|
extern PGDLLIMPORT char *GUC_check_errmsg_string;
|
|
|
|
|
extern PGDLLIMPORT char *GUC_check_errdetail_string;
|
|
|
|
|
extern PGDLLIMPORT char *GUC_check_errhint_string;
|
|
|
|
|
|
|
|
|
|
extern void GUC_check_errcode(int sqlerrcode);
|
|
|
|
|
|
|
|
|
|
#define GUC_check_errmsg \
|
|
|
|
|
pre_format_elog_string(errno, TEXTDOMAIN), \
|
|
|
|
|
GUC_check_errmsg_string = format_elog_string
|
|
|
|
|
|
|
|
|
|
#define GUC_check_errdetail \
|
|
|
|
|
pre_format_elog_string(errno, TEXTDOMAIN), \
|
|
|
|
|
GUC_check_errdetail_string = format_elog_string
|
|
|
|
|
|
|
|
|
|
#define GUC_check_errhint \
|
|
|
|
|
pre_format_elog_string(errno, TEXTDOMAIN), \
|
|
|
|
|
GUC_check_errhint_string = format_elog_string
|
|
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
8 years ago
|
|
|
#endif /* GUC_H */
|
