2003-04-25 21:45:10 +02:00
|
|
|
/*--------------------------------------------------------------------
|
2000-05-31 02:28:42 +02:00
|
|
|
* guc.h
|
|
|
|
|
*
|
|
|
|
|
* External declarations pertaining to backend/utils/misc/guc.c and
|
|
|
|
|
* backend/utils/misc/guc-file.l
|
|
|
|
|
*
|
2018-01-03 05:30:12 +01:00
|
|
|
* Copyright (c) 2000-2018, PostgreSQL Global Development Group
|
2003-04-25 21:45:10 +02:00
|
|
|
* Written by Peter Eisentraut <peter_e@gmx.net>.
|
|
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/utils/guc.h
|
2003-04-25 21:45:10 +02:00
|
|
|
*--------------------------------------------------------------------
|
2000-05-31 02:28:42 +02:00
|
|
|
*/
|
|
|
|
|
#ifndef GUC_H
|
|
|
|
|
#define GUC_H
|
|
|
|
|
|
2007-09-03 20:46:30 +02:00
|
|
|
#include "nodes/parsenodes.h"
|
2003-05-06 22:26:28 +02:00
|
|
|
#include "tcop/dest.h"
|
2002-03-01 23:45:19 +01:00
|
|
|
#include "utils/array.h"
|
|
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
|
2014-11-11 13:08:21 +01:00
|
|
|
/* 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
|
|
|
|
|
|
2014-12-04 01:54:01 +01:00
|
|
|
/*
|
|
|
|
|
* 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"
|
|
|
|
|
|
2000-05-31 02:28:42 +02:00
|
|
|
/*
|
2000-06-23 00:31:24 +02:00
|
|
|
* Certain options can only be set at certain times. The rules are
|
|
|
|
|
* like this:
|
|
|
|
|
*
|
2003-04-25 21:45:10 +02:00
|
|
|
* 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.
|
|
|
|
|
*
|
2000-06-23 00:31:24 +02:00
|
|
|
* 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
|
2006-03-07 04:01:22 +01:00
|
|
|
* 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.)
|
2000-06-23 00:31:24 +02:00
|
|
|
*
|
2014-09-14 03:01:49 +02:00
|
|
|
* 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.
|
2000-06-23 00:31:24 +02:00
|
|
|
*
|
|
|
|
|
* SUSET options can be set at postmaster startup, with the SIGHUP
|
2014-09-14 03:01:49 +02:00
|
|
|
* mechanism, or from the startup packet or SQL if you're a superuser.
|
2000-06-23 00:31:24 +02:00
|
|
|
*
|
|
|
|
|
* USERSET options can be set by anyone any time.
|
2000-05-31 02:28:42 +02:00
|
|
|
*/
|
2001-03-22 05:01:46 +01:00
|
|
|
typedef enum
|
|
|
|
|
{
|
2003-07-28 21:31:32 +02:00
|
|
|
PGC_INTERNAL,
|
|
|
|
|
PGC_POSTMASTER,
|
|
|
|
|
PGC_SIGHUP,
|
2014-09-14 03:01:49 +02:00
|
|
|
PGC_SU_BACKEND,
|
2003-07-28 21:31:32 +02:00
|
|
|
PGC_BACKEND,
|
|
|
|
|
PGC_SUSET,
|
|
|
|
|
PGC_USERSET
|
2000-05-31 02:28:42 +02:00
|
|
|
} GucContext;
|
|
|
|
|
|
2002-02-23 02:31:37 +01:00
|
|
|
/*
|
|
|
|
|
* 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
|
2002-05-17 03:19:19 +02:00
|
|
|
* 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
|
2003-04-25 21:45:10 +02:00
|
|
|
* as the current value. Note that source == PGC_S_OVERRIDE should be
|
|
|
|
|
* used when setting a PGC_INTERNAL option.
|
2003-07-27 06:35:54 +02:00
|
|
|
*
|
2004-11-14 20:35:35 +01:00
|
|
|
* PGC_S_INTERACTIVE isn't actually a source value, but is the
|
2004-01-19 20:04:40 +01:00
|
|
|
* dividing line between "interactive" and "non-interactive" sources for
|
|
|
|
|
* error reporting purposes.
|
|
|
|
|
*
|
2013-09-04 00:56:22 +02:00
|
|
|
* PGC_S_TEST is used when testing values to be used later ("doit" will always
|
|
|
|
|
* be false, so this never gets stored as the actual source of any value).
|
|
|
|
|
* 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.
|
2009-10-13 16:18:40 +02:00
|
|
|
*
|
|
|
|
|
* NB: see GucSource_Names in guc.c if you change this.
|
2002-02-23 02:31:37 +01:00
|
|
|
*/
|
|
|
|
|
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.
2011-05-12 01:57:38 +02:00
|
|
|
PGC_S_DEFAULT, /* hard-wired default ("boot_val") */
|
|
|
|
|
PGC_S_DYNAMIC_DEFAULT, /* default computed during initialization */
|
2003-07-28 21:31:32 +02:00
|
|
|
PGC_S_ENV_VAR, /* postmaster environment variable */
|
|
|
|
|
PGC_S_FILE, /* postgresql.conf */
|
|
|
|
|
PGC_S_ARGV, /* postmaster command line */
|
2013-02-18 05:45:36 +01:00
|
|
|
PGC_S_GLOBAL, /* global in-database setting */
|
2003-07-28 21:31:32 +02:00
|
|
|
PGC_S_DATABASE, /* per-database setting */
|
|
|
|
|
PGC_S_USER, /* per-user setting */
|
2009-10-08 00:14:26 +02:00
|
|
|
PGC_S_DATABASE_USER, /* per-user-and-database setting */
|
2003-07-28 21:31:32 +02:00
|
|
|
PGC_S_CLIENT, /* from client connection request */
|
|
|
|
|
PGC_S_OVERRIDE, /* special case to forcibly set default */
|
2004-01-19 20:04:40 +01:00
|
|
|
PGC_S_INTERACTIVE, /* dividing line for error reporting */
|
|
|
|
|
PGC_S_TEST, /* test per-database or per-user setting */
|
2003-07-28 21:31:32 +02:00
|
|
|
PGC_S_SESSION /* SET command */
|
2002-02-23 02:31:37 +01:00
|
|
|
} GucSource;
|
2000-05-31 02:28:42 +02:00
|
|
|
|
2010-12-03 14:44:15 +01:00
|
|
|
/*
|
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.
2015-06-29 00:06:14 +02:00
|
|
|
* 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.
|
2010-12-03 14:44:15 +01:00
|
|
|
*/
|
|
|
|
|
typedef struct ConfigVariable
|
|
|
|
|
{
|
2011-04-10 17:42:00 +02:00
|
|
|
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.
2015-06-29 00:06:14 +02:00
|
|
|
char *errmsg;
|
2010-12-03 14:44:15 +01:00
|
|
|
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.
2015-06-29 00:06:14 +02:00
|
|
|
bool ignore;
|
|
|
|
|
bool applied;
|
2011-04-10 17:42:00 +02:00
|
|
|
struct ConfigVariable *next;
|
2010-12-03 14:44:15 +01:00
|
|
|
} 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.
2015-06-29 00:06:14 +02:00
|
|
|
extern bool ParseConfigFile(const char *config_file, bool strict,
|
|
|
|
|
const char *calling_file, int calling_lineno,
|
|
|
|
|
int depth, int elevel,
|
2010-12-03 14:44:15 +01:00
|
|
|
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);
|
2012-09-24 16:55:53 +02:00
|
|
|
extern bool ParseConfigDirectory(const char *includedir,
|
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.
2015-06-29 00:06:14 +02:00
|
|
|
const char *calling_file, int calling_lineno,
|
2012-09-24 16:55:53 +02:00
|
|
|
int depth, int elevel,
|
|
|
|
|
ConfigVariable **head_p,
|
|
|
|
|
ConfigVariable **tail_p);
|
2010-12-03 14:44:15 +01:00
|
|
|
extern void FreeConfigVariables(ConfigVariable *list);
|
|
|
|
|
|
2008-03-16 17:42:44 +01:00
|
|
|
/*
|
2011-04-07 06:11:01 +02:00
|
|
|
* 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.
|
2008-03-16 17:42:44 +01:00
|
|
|
*/
|
|
|
|
|
struct config_enum_entry
|
|
|
|
|
{
|
|
|
|
|
const char *name;
|
2009-06-11 16:49:15 +02:00
|
|
|
int val;
|
2008-05-28 11:04:06 +02:00
|
|
|
bool hidden;
|
2008-03-16 17:42:44 +01:00
|
|
|
};
|
|
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
/*
|
|
|
|
|
* 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
2004-05-26 17:07:41 +02:00
|
|
|
|
2004-08-29 07:07:03 +02:00
|
|
|
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
2004-05-26 17:07:41 +02:00
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
/*
|
|
|
|
|
* Miscellaneous
|
|
|
|
|
*/
|
2007-09-11 02:06:42 +02:00
|
|
|
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.
2011-10-06 02:44:16 +02:00
|
|
|
GUC_ACTION_SAVE /* function SET option, or temp assignment */
|
2007-11-15 23:25:18 +01:00
|
|
|
} GucAction;
|
2007-09-11 02:06:42 +02:00
|
|
|
|
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
2004-05-26 17:07:41 +02:00
|
|
|
#define GUC_QUALIFIER_SEPARATOR '.'
|
|
|
|
|
|
2008-11-19 02:10:24 +01:00
|
|
|
/*
|
|
|
|
|
* 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 */
|
|
|
|
|
#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 */
|
2015-02-23 17:33:16 +01:00
|
|
|
#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
2017-06-21 21:18:54 +02:00
|
|
|
#define GUC_DISALLOW_IN_AUTO_FILE 0x0800 /* can't set in
|
|
|
|
|
* PG_AUTOCONF_FILENAME */
|
2008-11-19 02:10:24 +01:00
|
|
|
|
2015-02-23 17:33:16 +01:00
|
|
|
#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 */
|
2017-04-05 00:00:01 +02:00
|
|
|
#define GUC_UNIT_MB 0x4000 /* value is in megabytes */
|
2017-09-12 21:13:12 +02:00
|
|
|
#define GUC_UNIT_BYTE 0x8000 /* value is in bytes */
|
2016-10-03 22:40:05 +02:00
|
|
|
#define GUC_UNIT_MEMORY 0xF000 /* mask for size-related units */
|
2008-11-19 02:10:24 +01:00
|
|
|
|
2015-02-23 17:33:16 +01:00
|
|
|
#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 */
|
2016-10-03 22:40:05 +02:00
|
|
|
#define GUC_UNIT_TIME 0xF0000 /* mask for time-related units */
|
2008-11-19 02:10:24 +01:00
|
|
|
|
2015-02-23 17:06:16 +01:00
|
|
|
#define GUC_UNIT (GUC_UNIT_MEMORY | GUC_UNIT_TIME)
|
|
|
|
|
|
2009-09-04 00:08:05 +02:00
|
|
|
|
2003-04-25 21:45:10 +02:00
|
|
|
/* GUC vars that are actually declared in guc.c, rather than elsewhere */
|
|
|
|
|
extern bool log_duration;
|
|
|
|
|
extern bool Debug_print_plan;
|
|
|
|
|
extern bool Debug_print_parse;
|
|
|
|
|
extern bool Debug_print_rewritten;
|
|
|
|
|
extern bool Debug_pretty_print;
|
|
|
|
|
|
|
|
|
|
extern bool log_parser_stats;
|
|
|
|
|
extern bool log_planner_stats;
|
|
|
|
|
extern bool log_executor_stats;
|
|
|
|
|
extern bool log_statement_stats;
|
|
|
|
|
extern bool log_btree_build_stats;
|
|
|
|
|
|
2007-07-25 14:22:54 +02:00
|
|
|
extern PGDLLIMPORT bool check_function_bodies;
|
2003-12-01 23:08:02 +01:00
|
|
|
extern bool default_with_oids;
|
2017-11-29 15:24:24 +01:00
|
|
|
extern bool session_auth_is_superuser;
|
2003-12-01 23:08:02 +01:00
|
|
|
|
2003-04-25 21:45:10 +02:00
|
|
|
extern int log_min_error_statement;
|
2017-12-05 15:23:57 +01:00
|
|
|
extern PGDLLIMPORT int log_min_messages;
|
|
|
|
|
extern PGDLLIMPORT int client_min_messages;
|
2003-07-28 21:31:32 +02:00
|
|
|
extern int log_min_duration_statement;
|
2007-01-09 22:31:17 +01:00
|
|
|
extern int log_temp_files;
|
2003-04-25 21:45:10 +02:00
|
|
|
|
2011-07-17 20:19:31 +02:00
|
|
|
extern int temp_file_limit;
|
|
|
|
|
|
2005-03-20 00:27:11 +01:00
|
|
|
extern int num_temp_buffers;
|
|
|
|
|
|
2014-06-29 14:15:09 +02:00
|
|
|
extern char *cluster_name;
|
2017-12-05 15:23:57 +01:00
|
|
|
extern PGDLLIMPORT char *ConfigFileName;
|
2004-10-10 01:13:22 +02:00
|
|
|
extern char *HbaFileName;
|
|
|
|
|
extern char *IdentFileName;
|
|
|
|
|
extern char *external_pid_file;
|
2004-07-11 02:18:45 +02:00
|
|
|
|
2018-02-09 21:54:45 +01:00
|
|
|
extern PGDLLIMPORT char *application_name;
|
2009-11-29 00:38:08 +01:00
|
|
|
|
2005-10-15 04:49:52 +02:00
|
|
|
extern int tcp_keepalives_idle;
|
|
|
|
|
extern int tcp_keepalives_interval;
|
|
|
|
|
extern int tcp_keepalives_count;
|
2003-04-25 21:45:10 +02:00
|
|
|
|
2015-04-02 20:02:55 +02:00
|
|
|
#ifdef TRACE_SORT
|
|
|
|
|
extern bool trace_sort;
|
|
|
|
|
#endif
|
|
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
/*
|
|
|
|
|
* Functions exported by guc.c
|
|
|
|
|
*/
|
2001-06-13 00:54:06 +02:00
|
|
|
extern void SetConfigOption(const char *name, const char *value,
|
2002-02-23 02:31:37 +01:00
|
|
|
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
2004-05-26 17:07:41 +02:00
|
|
|
|
|
|
|
|
extern void DefineCustomBoolVariable(
|
2004-08-29 07:07:03 +02:00
|
|
|
const char *name,
|
|
|
|
|
const char *short_desc,
|
|
|
|
|
const char *long_desc,
|
|
|
|
|
bool *valueAddr,
|
2008-11-19 02:10:24 +01:00
|
|
|
bool bootValue,
|
2004-08-29 07:07:03 +02:00
|
|
|
GucContext context,
|
2008-11-19 02:10:24 +01:00
|
|
|
int flags,
|
2011-04-07 06:11:01 +02:00
|
|
|
GucBoolCheckHook check_hook,
|
2004-08-29 07:07:03 +02:00
|
|
|
GucBoolAssignHook assign_hook,
|
|
|
|
|
GucShowHook show_hook);
|
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
2004-05-26 17:07:41 +02:00
|
|
|
|
|
|
|
|
extern void DefineCustomIntVariable(
|
2004-08-29 07:07:03 +02:00
|
|
|
const char *name,
|
|
|
|
|
const char *short_desc,
|
|
|
|
|
const char *long_desc,
|
|
|
|
|
int *valueAddr,
|
2008-11-19 02:10:24 +01:00
|
|
|
int bootValue,
|
2005-03-25 17:17:28 +01:00
|
|
|
int minValue,
|
|
|
|
|
int maxValue,
|
2004-08-29 07:07:03 +02:00
|
|
|
GucContext context,
|
2008-11-19 02:10:24 +01:00
|
|
|
int flags,
|
2011-04-07 06:11:01 +02:00
|
|
|
GucIntCheckHook check_hook,
|
2004-08-29 07:07:03 +02:00
|
|
|
GucIntAssignHook assign_hook,
|
|
|
|
|
GucShowHook show_hook);
|
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
2004-05-26 17:07:41 +02:00
|
|
|
|
|
|
|
|
extern void DefineCustomRealVariable(
|
2004-08-29 07:07:03 +02:00
|
|
|
const char *name,
|
|
|
|
|
const char *short_desc,
|
|
|
|
|
const char *long_desc,
|
|
|
|
|
double *valueAddr,
|
2008-11-19 02:10:24 +01:00
|
|
|
double bootValue,
|
2005-03-25 17:17:28 +01:00
|
|
|
double minValue,
|
|
|
|
|
double maxValue,
|
2004-08-29 07:07:03 +02:00
|
|
|
GucContext context,
|
2008-11-19 02:10:24 +01:00
|
|
|
int flags,
|
2011-04-07 06:11:01 +02:00
|
|
|
GucRealCheckHook check_hook,
|
2004-08-29 07:07:03 +02:00
|
|
|
GucRealAssignHook assign_hook,
|
|
|
|
|
GucShowHook show_hook);
|
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
2004-05-26 17:07:41 +02:00
|
|
|
|
|
|
|
|
extern void DefineCustomStringVariable(
|
2004-08-29 07:07:03 +02:00
|
|
|
const char *name,
|
|
|
|
|
const char *short_desc,
|
|
|
|
|
const char *long_desc,
|
|
|
|
|
char **valueAddr,
|
2008-11-19 02:10:24 +01:00
|
|
|
const char *bootValue,
|
2004-08-29 07:07:03 +02:00
|
|
|
GucContext context,
|
2008-11-19 02:10:24 +01:00
|
|
|
int flags,
|
2011-04-07 06:11:01 +02:00
|
|
|
GucStringCheckHook check_hook,
|
2004-08-29 07:07:03 +02:00
|
|
|
GucStringAssignHook assign_hook,
|
|
|
|
|
GucShowHook show_hook);
|
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
2004-05-26 17:07:41 +02:00
|
|
|
|
2008-03-16 17:42:44 +01:00
|
|
|
extern void DefineCustomEnumVariable(
|
2009-06-11 16:49:15 +02:00
|
|
|
const char *name,
|
|
|
|
|
const char *short_desc,
|
|
|
|
|
const char *long_desc,
|
|
|
|
|
int *valueAddr,
|
|
|
|
|
int bootValue,
|
2017-06-21 20:39:04 +02:00
|
|
|
const struct config_enum_entry *options,
|
2009-06-11 16:49:15 +02:00
|
|
|
GucContext context,
|
|
|
|
|
int flags,
|
2011-04-07 06:11:01 +02:00
|
|
|
GucEnumCheckHook check_hook,
|
2009-06-11 16:49:15 +02:00
|
|
|
GucEnumAssignHook assign_hook,
|
|
|
|
|
GucShowHook show_hook);
|
2008-03-16 17:42:44 +01:00
|
|
|
|
2004-08-29 07:07:03 +02:00
|
|
|
extern void EmitWarningsOnPlaceholders(const char *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
2004-05-26 17:07:41 +02:00
|
|
|
|
2011-07-08 23:02:58 +02:00
|
|
|
extern const char *GetConfigOption(const char *name, bool missing_ok,
|
|
|
|
|
bool restrict_superuser);
|
2002-05-17 03:19:19 +02:00
|
|
|
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
2018-03-22 01:03:28 +01:00
|
|
|
extern int GetConfigOptionFlags(const char *name, bool missing_ok);
|
2001-06-13 00:54:06 +02:00
|
|
|
extern void ProcessConfigFile(GucContext context);
|
2002-05-17 03:19:19 +02:00
|
|
|
extern void InitializeGUCOptions(void);
|
2004-10-08 03:36:36 +02:00
|
|
|
extern bool SelectConfigFiles(const char *userDoption, const char *progname);
|
2002-05-17 03:19:19 +02:00
|
|
|
extern void ResetAllOptions(void);
|
2007-09-03 02:39:26 +02:00
|
|
|
extern void AtStart_GUC(void);
|
|
|
|
|
extern int NewGUCNestLevel(void);
|
|
|
|
|
extern void AtEOXact_GUC(bool isCommit, int nestLevel);
|
2003-04-25 21:45:10 +02:00
|
|
|
extern void BeginReportingGUCOptions(void);
|
2001-06-13 00:54:06 +02:00
|
|
|
extern void ParseLongOption(const char *string, char **name, char **value);
|
2008-07-23 19:29:53 +02:00
|
|
|
extern bool parse_int(const char *value, int *result, int flags,
|
2009-06-11 16:49:15 +02:00
|
|
|
const char **hintmsg);
|
2008-07-23 19:29:53 +02:00
|
|
|
extern bool parse_real(const char *value, double *result);
|
2012-06-10 21:20:04 +02:00
|
|
|
extern int set_config_option(const char *name, const char *value,
|
2002-09-04 22:31:48 +02:00
|
|
|
GucContext context, GucSource source,
|
2014-11-24 22:13:11 +01:00
|
|
|
GucAction action, bool changeVal, int elevel,
|
|
|
|
|
bool is_reload);
|
2014-05-06 18:12:18 +02:00
|
|
|
extern void AlterSystemSetConfigFile(AlterSystemStmt *setstmt);
|
2015-07-02 22:40:55 +02:00
|
|
|
extern char *GetConfigOptionByName(const char *name, const char **varname,
|
|
|
|
|
bool missing_ok);
|
2003-07-27 06:35:54 +02:00
|
|
|
extern void GetConfigOptionByNum(int varnum, const char **values, bool *noshow);
|
2002-09-04 22:31:48 +02:00
|
|
|
extern int GetNumConfigOptions(void);
|
2000-05-31 02:28:42 +02:00
|
|
|
|
2002-05-17 03:19:19 +02:00
|
|
|
extern void SetPGVariable(const char *name, List *args, bool is_local);
|
2003-05-06 22:26:28 +02:00
|
|
|
extern void GetPGVariable(const char *name, DestReceiver *dest);
|
|
|
|
|
extern TupleDesc GetPGVariableResultDesc(const char *name);
|
2002-05-17 03:19:19 +02:00
|
|
|
|
2013-10-04 19:50:28 +02:00
|
|
|
extern void ExecSetVariableStmt(VariableSetStmt *stmt, bool isTopLevel);
|
2007-09-03 20:46:30 +02:00
|
|
|
extern char *ExtractSetVariableArgs(VariableSetStmt *stmt);
|
2002-05-17 03:19:19 +02:00
|
|
|
|
2007-09-03 02:39:26 +02:00
|
|
|
extern void ProcessGUCArray(ArrayType *array,
|
2007-09-11 02:06:42 +02:00
|
|
|
GucContext context, GucSource source, GucAction action);
|
2002-03-01 23:45:19 +01:00
|
|
|
extern ArrayType *GUCArrayAdd(ArrayType *array, const char *name, const char *value);
|
|
|
|
|
extern ArrayType *GUCArrayDelete(ArrayType *array, const char *name);
|
2010-03-25 15:44:34 +01:00
|
|
|
extern ArrayType *GUCArrayReset(ArrayType *array);
|
2000-05-31 02:28:42 +02:00
|
|
|
|
2003-05-03 00:02:47 +02:00
|
|
|
#ifdef EXEC_BACKEND
|
2004-05-28 07:13:32 +02:00
|
|
|
extern void write_nondefault_variables(GucContext context);
|
|
|
|
|
extern void read_nondefault_variables(void);
|
2003-05-03 00:02:47 +02:00
|
|
|
#endif
|
|
|
|
|
|
2014-11-24 22:13:11 +01:00
|
|
|
/* GUC serialization */
|
|
|
|
|
extern Size EstimateGUCStateSpace(void);
|
|
|
|
|
extern void SerializeGUCState(Size maxsize, char *start_address);
|
|
|
|
|
extern void RestoreGUCState(void *gucstate);
|
|
|
|
|
|
2011-04-07 06:11:01 +02:00
|
|
|
/* 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
|
|
|
|
|
|
|
|
|
|
|
2004-01-19 20:04:40 +01:00
|
|
|
/*
|
|
|
|
|
* The following functions are not in guc.c, but are declared here to avoid
|
|
|
|
|
* having to include guc.h in some widely used headers that it really doesn't
|
|
|
|
|
* belong in.
|
|
|
|
|
*/
|
|
|
|
|
|
2004-11-05 20:17:13 +01:00
|
|
|
/* in commands/tablespace.c */
|
2011-04-07 06:11:01 +02:00
|
|
|
extern bool check_default_tablespace(char **newval, void **extra, GucSource source);
|
|
|
|
|
extern bool check_temp_tablespaces(char **newval, void **extra, GucSource source);
|
|
|
|
|
extern void assign_temp_tablespaces(const char *newval, void *extra);
|
2004-11-05 20:17:13 +01:00
|
|
|
|
2004-01-19 20:04:40 +01:00
|
|
|
/* in catalog/namespace.c */
|
2011-04-07 06:11:01 +02:00
|
|
|
extern bool check_search_path(char **newval, void **extra, GucSource source);
|
|
|
|
|
extern void assign_search_path(const char *newval, void *extra);
|
2004-08-29 07:07:03 +02:00
|
|
|
|
2004-01-19 20:04:40 +01:00
|
|
|
/* in access/transam/xlog.c */
|
2011-04-07 06:11:01 +02:00
|
|
|
extern bool check_wal_buffers(int *newval, void **extra, GucSource source);
|
2014-01-27 06:05:49 +01:00
|
|
|
extern void assign_xlog_sync_method(int new_sync_method, void *extra);
|
|
|
|
|
|
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
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* GUC_H */
|
