/*
 * 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 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).  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 sql if you're a superuser.
 *
 * USERSET options can be set by anyone any time.
 */
typedef enum
{
	PGC_INTERNAL,PGC_POSTMASTER,PGC_SIGHUP,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.  Note that source == PGC_S_OVERRIDE should be
 * used when setting a PGC_INTERNAL option.
 *
 * 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 stored as per-database or
 * per-user defaults ("doit" will always be false,so this never gets stored
 * as the actual source of any value).	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.
 *
 * NB: see GucSource_Names in guc.c if you change this.
 */
typedef enum
{
	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_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;

/*
Per-Variable Hooks
------------------
Each variable known to GUC can optionally have a check_hook,an
assign_hook,and/or a show_hook to provide customized behavior.
Check hooks are used to perform validity checking on variable values
(above and beyond what GUC can do),to compute derived settings when
nontrivial work is needed to do that,and optionally to "canonicalize"
user-supplied values. Assign hooks are used to update any derived state
that needs to change when a GUC variable is set. Show hooks are used to
modify the default SHOW display for a variable.

If a check_hook is provided,it points to a function of the signature
bool check_hook(datatype *newvalue,void **extra,GucSource source)
The "newvalue" argument is of type bool *,int *,double *,or char **
for bool,int/enum,real,or string variables respectively. The check
function should validate the proposed new value,and return true if it is
OK or false if not. The function can optionally do a few other things:
* When rejecting a bad proposed value,it may be useful to append some
additional information to the generic "invalid value for parameter FOO"
complaint that guc.c will emit. To do that,call
void GUC_check_errdetail(const char *format,...)
where the format string and additional arguments follow the rules for
errdetail() arguments. The resulting string will be emitted as the
DETAIL line of guc.c's error report,so it should follow the message style
guidelines for DETAIL messages. There is also
void GUC_check_errhint(const char *format,...)
which can be used in the same way to append a HINT message.
Occasionally it may even be appropriate to override guc.c's generic primary
message or error code,which can be done with
void GUC_check_errcode(int sqlerrcode)
void GUC_check_errmsg(const char *format,...)
In general,check_hooks should avoid throwing errors directly if possible,though this may be impractical to avoid for some corner cases such as
out-of-memory.
* Since the newvalue is pass-by-reference,the function can modify it.
This might be used for example to canonicalize the spelling of a string
value,round off a buffer size to the nearest supported value,or replace
a special value such as "-1" with a computed default value. If the
function wishes to replace a string value,it must malloc (not palloc)
the replacement value,and be sure to free() the prevIoUs value.
* Derived information,such as the role OID represented by a user name,can be stored for use by the assign hook. To do this,malloc (not palloc)
storage space for the information,and return its address at *extra.
guc.c will automatically free() this space when the associated GUC setting
is no longer of interest. *extra is initialized to NULL before call,so
it can be ignored if not needed.
The "source" argument indicates the source of the proposed new value,If it is >= PGC_S_INTERACTIVE,then we are performing an interactive
assignment (e.g.,a SET command). But when source < PGC_S_INTERACTIVE,we are reading a non-interactive option source,such as postgresql.conf.
This is sometimes needed to determine whether a setting should be
allowed. The check_hook might also look at the current actual value of
the variable to determine what is allowed.
Note that check hooks are sometimes called just to validate a value,without any intention of actually changing the setting. Therefore the
check hook must *not* take any action based on the assumption that an
assignment will occur.

If an assign_hook is provided,it points to a function of the signature
void assign_hook(datatype newvalue,void *extra)
where the type of "newvalue" matches the kind of variable,and "extra"
is the derived-information pointer returned by the check_hook (always
NULL if there is no check_hook). This function is called immediately
before actually setting the variable's value (so it can look at the actual
variable to determine the old value,for example to avoid doing work when
the value isn't really changing).
Note that there is no provision for a failure result code. assign_hooks
should never fail except under the most dire circumstances,since a failure
may for example result in GUC settings not being rolled back properly during
transaction abort. In general,try to do anything that could conceivably
fail in a check_hook instead,and pass along the results in an "extra"
struct,so that the assign hook has little to do beyond copying the data to
someplace. This applies particularly to catalog lookups: any required
lookups must be done in the check_hook,since the assign_hook may be
executed during transaction rollback when lookups will be unsafe.
Note that check_hooks are sometimes called outside any transaction,too.
This happens when processing the wired-in "bootstrap" value,values coming
from the postmaster command line or environment,or values coming from
postgresql.conf. Therefore,any catalog lookups done in a check_hook
should be guarded with an IsTransactionState() test,and there must be a
fallback path to allow derived values to be computed during the first
subsequent use of the GUC setting within a transaction. A typical
arrangement is for the catalog values computed by the check_hook and
installed by the assign_hook to be used only for the remainder of the
transaction in which the new setting is made. Each subsequent transaction
looks up the values afresh on first use. This arrangement is useful to
prevent use of stale catalog values,independently of the problem of
needing to check GUC values outside a transaction.

If a show_hook is provided,it points to a function of the signature
const char *show_hook(void)
This hook allows variable-specific computation of the value displayed
by SHOW (and other sql features for showing GUC variable values).
The return value can point to a static buffer,since show functions are
not used re-entrantly.






*/

/*
* Contents of GUC tables
*
* See src/backend/utils/misc/README for design notes.
*
* TO ADD AN OPTION:
*
* 1. Declare a global variable of type bool,int,double,or char*
* and make use of it.
*
* 2. Decide at what times it's safe to set the option. See guc.h for
* details.
*
* 3. Decide on a name,a default value,upper and lower bounds (if
* applicable),etc.
*
* 4. Add a record below.
*
* 5. Add it to src/backend/utils/misc/postgresql.conf.sample,if
* appropriate.
*
* 6. Don't forget to document the option (at least in config.sgml).
*
* 7. If it's a new GUC_LIST option you must edit pg_dumpall.c to ensure
* it is not single quoted at dump time.
*/
/*
要增加参数的话，在需要的c文件增加定义，在对应的h文件 xtern PGDLLIMPORT 增加声明，在 /src/backend/utils/misc/guc.c 根据参数不同的数据类型，去不同的数组里面增加，之后就可以在postgre.conf里面指定值了，
这是最简单的方法，pg是多进程的，在一个进程中指定参数值，是没有改变全局值的，改变全局值需要给主进程发信号，主进程重新读postgre.conf
*/