head	1.10;
access;
symbols
	REL9_0_0:1.10
	REL9_1_ALPHA1:1.10
	REL9_0_RC1:1.10
	REL9_0_BETA4:1.10
	REL9_0_STABLE:1.10.0.14
	REL9_0_BETA3:1.10
	REL9_0_BETA2:1.10
	REL7_4_29:1.2
	REL8_0_25:1.5
	REL8_1_21:1.5
	REL8_2_17:1.5
	REL8_3_11:1.8
	REL8_4_4:1.10
	REL9_0_BETA1:1.10
	REL9_0_ALPHA5_BRANCH:1.10.0.12
	REL9_0_ALPHA5:1.10
	REL7_4_28:1.2
	REL8_0_24:1.5
	REL8_1_20:1.5
	REL8_2_16:1.5
	REL8_3_10:1.8
	REL8_4_3:1.10
	REL9_0_ALPHA4:1.10
	REL9_0_ALPHA4_BRANCH:1.10.0.10
	REL8_5_ALPHA3:1.10
	REL8_5_ALPHA3_BRANCH:1.10.0.8
	REL7_4_27:1.2
	REL8_0_23:1.5
	REL8_1_19:1.5
	REL8_2_15:1.5
	REL8_3_9:1.8
	REL8_4_2:1.10
	REL8_5_ALPHA2:1.10
	REL8_5_ALPHA2_BRANCH:1.10.0.6
	REL7_4_26:1.2
	REL8_0_22:1.5
	REL8_1_18:1.5
	REL8_2_14:1.5
	REL8_3_8:1.8
	REL8_4_1:1.10
	REL8_5_ALPHA1:1.10
	REL8_5_ALPHA1_BRANCH:1.10.0.4
	REL8_4_STABLE:1.10.0.2
	REL8_4_0:1.10
	REL8_4_RC2:1.10
	REL8_4_RC1:1.10
	REL8_4_BETA2:1.10
	REL8_4_BETA1:1.10
	REL7_4_25:1.2
	REL8_0_21:1.5
	REL8_1_17:1.5
	REL8_2_13:1.5
	REL8_3_7:1.8
	REL7_4_24:1.2
	REL8_0_20:1.5
	REL8_1_16:1.5
	REL8_2_12:1.5
	REL8_3_6:1.8
	REL7_4_23:1.2
	REL8_0_19:1.5
	REL8_1_15:1.5
	REL8_2_11:1.5
	REL8_3_5:1.8
	REL7_4_22:1.2
	REL8_0_18:1.5
	REL8_1_14:1.5
	REL8_2_10:1.5
	REL8_3_4:1.8
	REL7_4_21:1.2
	REL8_0_17:1.5
	REL8_1_13:1.5
	REL8_2_9:1.5
	REL8_3_3:1.8
	REL7_4_20:1.2
	REL8_0_16:1.5
	REL8_1_12:1.5
	REL8_2_8:1.5
	REL8_3_2:1.8
	REL8_2_7:1.5
	REL8_3_1:1.8
	REL8_3_STABLE:1.8.0.2
	REL8_3_0:1.8
	REL8_3_RC2:1.8
	REL7_3_21:1.1
	REL7_4_19:1.2
	REL8_0_15:1.5
	REL8_1_11:1.5
	REL8_2_6:1.5
	REL8_3_RC1:1.8
	REL8_3_BETA4:1.7
	REL8_3_BETA3:1.7
	REL8_3_BETA2:1.7
	REL8_3_BETA1:1.7
	REL7_3_20:1.1
	REL7_4_18:1.2
	REL8_0_14:1.5
	REL8_1_10:1.5
	REL8_2_5:1.5
	REL7_3_19:1.1
	REL7_4_17:1.2
	REL8_0_13:1.5
	REL8_1_9:1.5
	REL8_2_4:1.5
	REL8_0_12:1.5
	REL8_1_8:1.5
	REL8_2_3:1.5
	REL7_3_18:1.1
	REL7_4_16:1.2
	REL8_0_11:1.5
	REL8_1_7:1.5
	REL8_2_2:1.5
	REL8_0_10:1.5
	REL8_1_6:1.5
	REL8_2_1:1.5
	REL7_4_15:1.2
	REL7_3_17:1.1
	REL8_2_STABLE:1.5.0.8
	REL8_2_0:1.5
	REL8_2_RC1:1.5
	REL8_2_BETA3:1.5
	REL8_2_BETA2:1.5
	REL8_1_5:1.5
	REL8_0_9:1.5
	REL7_4_14:1.2
	REL7_3_16:1.1
	REL8_2_BETA1:1.5
	REL7_3_15:1.1
	REL7_4_13:1.2
	REL8_0_8:1.5
	REL8_1_4:1.5
	REL7_3_14:1.1
	REL7_4_12:1.2
	REL8_0_7:1.5
	REL8_1_3:1.5
	REL7_3_13:1.1
	REL7_4_11:1.2
	REL8_0_6:1.5
	REL8_1_2:1.5
	REL7_3_12:1.1
	REL7_4_10:1.2
	REL8_0_5:1.5
	REL8_1_1:1.5
	REL8_1_STABLE:1.5.0.6
	REL8_1_0:1.5
	REL8_1_0RC1:1.5
	REL8_1_0BETA4:1.5
	REL8_1_0BETA3:1.5
	REL7_3_11:1.1
	REL7_4_9:1.2
	REL8_0_4:1.5
	REL8_1_0BETA2:1.5
	REL8_1_0BETA1:1.5
	REL7_3_10:1.1
	REL7_4_8:1.2
	REL8_0_3:1.5
	REL8_0_2:1.5
	REL7_3_9:1.1
	REL7_4_7:1.2
	REL8_0_1:1.5
	REL8_0_STABLE:1.5.0.4
	REL8_0_0:1.5.0.2
	REL8_0_0RC5:1.5
	REL8_0_0RC4:1.5
	REL8_0_0RC3:1.5
	REL8_0_0RC2:1.5
	REL8_0_0RC1:1.5
	REL8_0_0BETA5:1.5
	REL8_0_0BETA4:1.5
	REL7_4_6:1.2
	REL7_3_8:1.1
	REL8_0_0BETA3:1.5
	REL8_0_0BETA2:1.5
	REL7_4_5:1.2
	REL7_3_7:1.1
	REL7_4_4:1.2
	REL8_0_0BETA1:1.5
	REL7_4_3:1.2
	REL7_4_2:1.2
	REL7_3_6:1.1
	REL7_4_1:1.2
	REL7_3_5:1.1
	REL7_4:1.2
	REL7_4_RC2:1.2
	REL7_4_STABLE:1.2.0.4
	REL7_4_RC1:1.2
	REL7_4_BETA5:1.2
	REL7_4_BETA4:1.2
	REL7_4_BETA3:1.2
	REL7_4_BETA2:1.2
	WIN32_DEV:1.2.0.2
	REL7_4_BETA1:1.2
	REL7_3_4:1.1
	REL7_3_2:1.1
	REL7_3_STABLE:1.1.0.2;
locks; strict;
comment	@# @;


1.10
date	2008.03.20.17.55.15;	author momjian;	state Exp;
branches;
next	1.9;

1.9
date	2008.03.16.16.42.44;	author mha;	state Exp;
branches;
next	1.8;

1.8
date	2007.12.28.00.23.23;	author tgl;	state Exp;
branches;
next	1.7;

1.7
date	2007.09.11.00.06.42;	author tgl;	state Exp;
branches;
next	1.6;

1.6
date	2007.09.10.00.57.21;	author tgl;	state Exp;
branches;
next	1.5;

1.5
date	2004.07.01.00.51.24;	author tgl;	state Exp;
branches;
next	1.4;

1.4
date	2004.01.19.19.04.40;	author tgl;	state Exp;
branches;
next	1.3;

1.3
date	2003.11.29.19.52.03;	author pgsql;	state Exp;
branches;
next	1.2;

1.2
date	2003.07.29.00.03.18;	author tgl;	state Exp;
branches;
next	1.1;

1.1
date	2002.05.17.01.19.18;	author tgl;	state Exp;
branches;
next	;


desc
@@


1.10
log
@Make source code READMEs more consistent.  Add CVS tags to all README files.
@
text
@$PostgreSQL: pgsql/src/backend/utils/misc/README,v 1.9 2008/03/16 16:42:44 mha Exp $

Guc Implementation Notes
========================

The GUC (Grand Unified Configuration) module implements configuration
variables of multiple types (currently boolean, enum, int, float, and string).
Variable settings can come from various places, with a priority ordering
determining which setting is used.


Per-Variable Hooks
------------------

Each variable known to GUC can optionally have an assign_hook and/or
a show_hook to provide customized behavior.  Assign hooks are used to
perform validity checking on variable values (above and beyond what
GUC can do).  They are also 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 an assign_hook is provided, it points to a function of the signature
	bool assign_hook(newvalue, bool doit, GucSource source)
where the type of "newvalue" matches the kind of variable.  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).  If the
function returns "true" then the assignment is completed; if it returns
"false" then newvalue is considered invalid and the assignment is not
performed.  If "doit" is false then the function should simply check
validity of newvalue and not change any derived state.  The "source" parameter
indicates where the new value came from.  If it is >= PGC_S_INTERACTIVE,
then we are performing an interactive assignment (e.g., a SET command), and
ereport(ERROR) is safe to do.  But when source < PGC_S_INTERACTIVE, we are
reading a non-interactive option source, such as postgresql.conf.  In this
case the assign_hook should *not* ereport but should just return false if it
doesn't like the newvalue.

If an assign_hook returns false then guc.c will report a generic "invalid
value for option FOO" error message.  If you feel the need to provide a more
specific error message, ereport() it using "GUC_complaint_elevel(source)"
as the error level.  Note that this might return either ERROR or a lower level
such as LOG, so the ereport call might or might not return.  If it does
return, return false out of the assign_hook.

For string variables, the signature for assign hooks is a bit different:
	const char *assign_hook(const char *newvalue,
				bool doit,
				GucSource source)
The meanings of the parameters are the same as for the other types of GUC
variables, but the return value is handled differently:
	NULL --- assignment fails (like returning false for other datatypes)
	newvalue --- assignment succeeds, assign the newvalue as-is
	malloc'd (not palloc'd!!!) string --- assign that value instead
The third choice is allowed in case the assign_hook wants to return a
"canonical" version of the new value.  For example, the assign_hook for
datestyle always returns a string that includes both output and input
datestyle options, although the input might have specified only one.

Note that a string variable's assign_hook will NEVER be called with a NULL
value for newvalue, since there would be no way to distinguish success
and failure returns.  If the boot_val or reset_val for a string variable
is NULL, it will just be assigned without calling the assign_hook.
Therefore, a NULL boot_val should never be used in combination with an
assign_hook that has side-effects, as the side-effects wouldn't happen
during a RESET that re-institutes the boot-time setting.

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.


Saving/Restoring Guc Variable Values
------------------------------------

Prior values of configuration variables must be remembered in order to deal
with several special cases: RESET (a/k/a SET TO DEFAULT), rollback of SET
on transaction abort, rollback of SET LOCAL at transaction end (either
commit or abort), and save/restore around a function that has a SET option.
RESET is defined as selecting the value that would be effective had there
never been any SET commands in the current session.

To handle these cases we must keep track of many distinct values for each
variable.  The primary values are:

* actual variable contents	always the current effective value

* reset_val			the value to use for RESET

(Each GUC entry also has a boot_val which is the wired-in default value.
This is assigned to the reset_val and the actual variable during
InitializeGUCOptions().  The boot_val is also consulted to restore the
correct reset_val if SIGHUP processing discovers that a variable formerly
specified in postgresql.conf is no longer set there.)

In addition to the primary values, there is a stack of former effective
values that might need to be restored in future.  Stacking and unstacking
is controlled by the GUC "nest level", which is zero when outside any
transaction, one at top transaction level, and incremented for each
open subtransaction or function call with a SET option.  A stack entry
is made whenever a GUC variable is first modified at a given nesting level.
(Note: the reset_val need not be stacked because it is only changed by
non-transactional operations.)

A stack entry has a state, a prior value of the GUC variable, a remembered
source of that prior value, and depending on the state may also have a
"masked" value.  The masked value is needed when SET followed by SET LOCAL
occur at the same nest level: the SET's value is masked but must be
remembered to restore after transaction commit.

During initialization we set the actual value and reset_val based on
whichever non-interactive source has the highest priority.  They will
have the same value.

The possible transactional operations on a GUC value are:

Entry to a function with a SET option:

	Push a stack entry with the prior variable value and state SAVE,
	then set the variable.

Plain SET command:

	If no stack entry of current level:
		Push new stack entry w/prior value and state SET
	else if stack entry's state is SAVE, SET, or LOCAL:
		change stack state to SET, don't change saved value
		(here we are forgetting effects of prior set action)
	else (entry must have state SET+LOCAL):
		discard its masked value, change state to SET
		(here we are forgetting effects of prior SET and SET LOCAL)
	Now set new value.

SET LOCAL command:

	If no stack entry of current level:
		Push new stack entry w/prior value and state LOCAL
	else if stack entry's state is SAVE or LOCAL or SET+LOCAL:
		no change to stack entry
		(in SAVE case, SET LOCAL will be forgotten at func exit)
	else (entry must have state SET):
		put current active into its masked slot, set state SET+LOCAL
	Now set new value.

Transaction or subtransaction abort:

	Pop stack entries, restoring prior value, until top < subxact depth

Transaction or subtransaction commit (incl. successful function exit):

	While stack entry level >= subxact depth

		if entry's state is SAVE:
			pop, restoring prior value
		else if level is 1 and entry's state is SET+LOCAL:
			pop, restoring *masked* value
		else if level is 1 and entry's state is SET:
			pop, discarding old value
		else if level is 1 and entry's state is LOCAL:
			pop, restoring prior value
		else if there is no entry of exactly level N-1:
			decrement entry's level, no other state change
		else
			merge entries of level N-1 and N as specified below

The merged entry will have level N-1 and prior = older prior, so easiest
to keep older entry and free newer.  There are 12 possibilities since
we already handled level N state = SAVE:

N-1		N

SAVE		SET		discard top prior, set state SET
SAVE		LOCAL		discard top prior, no change to stack entry
SAVE		SET+LOCAL	discard top prior, copy masked, state S+L

SET		SET		discard top prior, no change to stack entry
SET		LOCAL		copy top prior to masked, state S+L
SET		SET+LOCAL	discard top prior, copy masked, state S+L

LOCAL		SET		discard top prior, set state SET
LOCAL		LOCAL		discard top prior, no change to stack entry
LOCAL		SET+LOCAL	discard top prior, copy masked, state S+L

SET+LOCAL	SET		discard top prior and second masked, state SET
SET+LOCAL	LOCAL		discard top prior, no change to stack entry
SET+LOCAL	SET+LOCAL	discard top prior, copy masked, state S+L


RESET is executed like a SET, but using the reset_val as the desired new
value.  (We do not provide a RESET LOCAL command, but SET LOCAL TO DEFAULT
has the same behavior that RESET LOCAL would.)  The source associated with
the reset_val also becomes associated with the actual value.

If SIGHUP is received, the GUC code rereads the postgresql.conf
configuration file (this does not happen in the signal handler, but at
next return to main loop; note that it can be executed while within a
transaction).  New values from postgresql.conf are assigned to actual
variable, reset_val, and stacked actual values, but only if each of
these has a current source priority <= PGC_S_FILE.  (It is thus possible
for reset_val to track the config-file setting even if there is
currently a different interactive value of the actual variable.)

The assign_hook and show_hook routines work only with the actual variable,
and are not directly aware of the additional values maintained by GUC.
This is not a problem for normal usage, since we can assign first to the
actual variable and then (if that succeeds) to the additional values as
needed.  However, for SIGHUP rereads we may not want to assign to the
actual variable.  Our procedure in that case is to call the assign_hook
with doit = false so that the value is validated, but no derived state is
changed.


String Memory Handling
----------------------

String option values are allocated with strdup, not with the
pstrdup/palloc mechanisms.  We would need to keep them in a permanent
context anyway, and strdup gives us more control over handling
out-of-memory failures.

We allow a string variable's actual value, reset_val, boot_val, and stacked
values to point at the same storage.  This makes it slightly harder to free
space (we must test whether a value to be freed isn't equal to any of the
other pointers in the GUC entry or associated stack items).  The main
advantage is that we never need to strdup during transaction commit/abort,
so cannot cause an out-of-memory failure there.
@


1.9
log
@Some cleanups of enum-guc code, per comments from Tom.
@
text
@d1 1
a1 1
$PostgreSQL: pgsql/src/backend/utils/misc/README,v 1.8 2007/12/28 00:23:23 tgl Exp $
d3 2
a4 2

GUC IMPLEMENTATION NOTES
d12 2
a13 1
PER-VARIABLE HOOKS
d73 2
a74 1
SAVING/RESTORING GUC VARIABLE VALUES
d213 2
a214 1
STRING MEMORY HANDLING
@


1.8
log
@Improve consistency of error reporting in GUC assign_hook routines.  Some
were reporting ERROR for interactive assignments and LOG for other cases,
some were saying nothing for non-interactive cases, and a few did yet other
things.  Make them use a new function GUC_complaint_elevel() to establish
a reasonably uniform policy about how to report.  There are still a few
edge cases such as assign_search_path(), but it's much better than before.
Per gripe from Devrim Gunduz and subsequent discussion.

As noted by Alvaro, it'd be better to fold these custom messages into the
standard "invalid parameter value" complaint from guc.c, perhaps as the DETAIL
field.  However that will require more redesign than seems prudent for 8.3.
This is a relatively safe, low-impact change that we can afford to risk now.
@
text
@d1 1
a1 1
$PostgreSQL: pgsql/src/backend/utils/misc/README,v 1.7 2007/09/11 00:06:42 tgl Exp $
d7 1
a7 1
variables of multiple types (currently boolean, int, float, and string).
@


1.7
log
@Arrange for SET LOCAL's effects to persist until the end of the current top
transaction, unless rolled back or overridden by a SET clause for the same
variable attached to a surrounding function call.  Per discussion, these
seem the best semantics.  Note that this is an INCOMPATIBLE CHANGE: in 8.0
through 8.2, SET LOCAL's effects disappeared at subtransaction commit
(leading to behavior that made little sense at the SQL level).

I took advantage of the opportunity to rewrite and simplify the GUC variable
save/restore logic a little bit.  The old idea of a "tentative" value is gone;
it was a hangover from before we had a stack.  Also, we no longer need a stack
entry for every nesting level, but only for those in which a variable's value
actually changed.
@
text
@d1 1
a1 1
$PostgreSQL: pgsql/src/backend/utils/misc/README,v 1.6 2007/09/10 00:57:21 tgl Exp $
d31 12
a42 10
then we are performing an interactive assignment (e.g., a SET command).
In such cases it is okay for the assign_hook to raise an error via ereport().
If the function returns false for an interactive assignment then guc.c will
report a generic "invalid value" error message.  (An internal ereport() in
an assign_hook is only needed if you want to generate a specialized error
message.)  But when source < PGC_S_INTERACTIVE, we are reading a
non-interactive option source, such as postgresql.conf.  In this case the
assign_hook should *not* ereport but should just return false if it doesn't
like the newvalue.  (An ereport(LOG) call would be acceptable if you feel a
need for a custom complaint in this situation.)
@


1.6
log
@Code review for GUC revert-values-if-removed-from-postgresql.conf patch;
and in passing, fix some bogosities dating from the custom_variable_classes
patch.  Fix guc-file.l to correctly check changes in custom_variable_classes
that are attempted concurrently with additions/removals of custom variables,
and don't allow the new setting to be applied in advance of checking it.
Clean up messy and undocumented situation for string variables with NULL
boot_val.  Fix DefineCustomVariable functions to initialize boot_val
correctly.  Prevent find_option from inserting bogus placeholders for custom
variables that are simply inquired about rather than being set.
@
text
@d1 1
a1 1
$PostgreSQL: pgsql/src/backend/utils/misc/README,v 1.5 2004/07/01 00:51:24 tgl Exp $
d72 6
a77 6
Prior values of configuration variables must be remembered in order to
deal with three special cases: RESET (a/k/a SET TO DEFAULT), rollback of
SET on transaction abort, and rollback of SET LOCAL at transaction end
(either commit or abort).  RESET is defined as selecting the value that
would be effective had there never been any SET commands in the current
session.
d84 1
a84 1
* reset_value			the value to use for RESET
d86 20
a105 1
* tentative_value		the uncommitted result of SET
d107 37
a143 11
The reason we need a tentative_value separate from the actual value is
that when a transaction does SET followed by SET LOCAL, the actual value
will now be the LOCAL value, but we want to remember the prior SET so that
that value is restored at transaction commit.

In addition, for each level of transaction (possibly nested) we have to
remember the transaction-entry-time actual and tentative values, in case
we need to restore them at transaction end.  (The RESET value is essentially
non-transactional, so it doesn't have to be stacked.)  For efficiency these
stack entries are not constructed until/unless the variable is actually SET
within a particular transaction.
d145 34
a178 3
During initialization we set the actual value and reset_value based on
whichever non-interactive source has the highest priority.  They will
have the same value.  The tentative_value is not meaningful at this point.
d180 3
a182 2
A SET command starts by stacking the existing actual and tentative values
if this hasn't already been done within the current transaction.  Then:
a183 14
A SET LOCAL command sets the actual variable (and nothing else).  At
transaction end, the stacked values are used to restore the GUC entry
to its pre-transaction state.

A SET (or SET SESSION) command sets the actual variable, and if no error,
then sets the tentative_value.  If the transaction commits, the
tentative_value is assigned again to the actual variable (which could by
now be different, if the SET was followed by SET LOCAL).  If the
transaction aborts, the stacked values are used to restore the GUC entry
to its pre-transaction state.

In the case of SET within nested subtransactions, at each commit the
tentative_value propagates out to the next transaction level.  It will
be thrown away at abort of any level, or after exiting the top transaction.
d185 1
a185 1
RESET is executed like a SET, but using the reset_value as the desired new
d188 1
a188 1
the reset_value also becomes associated with the actual and tentative values.
d194 1
a194 1
variable, reset_value, and stacked actual values, but only if each of
d196 1
a196 1
for reset_value to track the config-file setting even if there is
a198 4
Note that tentative_value is unused and undefined except between a SET
command and the end of the transaction.  Also notice that we must track
the source associated with each one of the values.

d216 6
a221 6
We allow a string variable's actual value, reset_val, tentative_val, and
stacked copies of same to point at the same storage.  This makes it
slightly harder to free space (must test whether a value to be freed isn't
equal to any of the other pointers in the GUC entry or associated stack
items).  The main advantage is that we never need to strdup during
transaction commit/abort, so cannot cause an out-of-memory failure there.
@


1.5
log
@Nested transactions.  There is still much left to do, especially on the
performance front, but with feature freeze upon us I think it's time to
drive a stake in the ground and say that this will be in 7.5.

Alvaro Herrera, with some help from Tom Lane.
@
text
@d1 1
a1 1
$PostgreSQL: pgsql-server/src/backend/utils/misc/README,v 1.4 2004/01/19 19:04:40 tgl Exp $
d56 8
@


1.4
log
@Repair problem identified by Olivier Prenant: ALTER DATABASE SET search_path
should not be too eager to reject paths involving unknown schemas, since
it can't really tell whether the schemas exist in the target database.
(Also, when reading pg_dumpall output, it could be that the schemas
don't exist yet, but eventually will.)  ALTER USER SET has a similar issue.
So, reduce the normal ERROR to a NOTICE when checking search_path values
for these commands.  Supporting this requires changing the API for GUC
assign_hook functions, which causes the patch to touch a lot of places,
but the changes are conceptually trivial.
@
text
@d1 1
a1 1
$PostgreSQL: pgsql-server/src/backend/utils/misc/README,v 1.3 2003/11/29 19:52:03 pgsql Exp $
d71 2
a72 2
To handle these cases we must keep track of as many as four distinct
values for each variable.  They are:
d78 1
a78 1
* session_value			the "committed" setting for the session
d80 15
a94 1
* tentative_value		the uncommitted result of SET
d96 2
a97 3
During initialization we set the first three of these (actual, reset_value,
and session_value) based on whichever non-interactive source has the
highest priority.  All three will have the same value.
d100 2
a101 2
transaction end, the session_value is used to restore the actual variable
to its pre-transaction value.
d105 8
a112 4
tentative_value is assigned to the session_value and the actual variable
(which could by now be different, if the SET was followed by SET LOCAL).
If the transaction aborts, the tentative_value is discarded and the
actual variable is restored from the session_value.
d117 1
a117 1
the reset_value also becomes associated with the actual and session values.
d123 4
a126 4
variable, reset_value, and session_value, but only if each of these has a
current source priority <= PGC_S_FILE.  (It is thus possible for
reset_value to track the config-file setting even if there is currently
a different interactive value of the actual variable.)
d130 1
a130 1
the source associated with each of the four values.
d149 6
a154 6
We allow a variable's actual value, reset_val, session_val, and
tentative_val to point at the same storage.  This makes it slightly harder
to free space (must test that the value to be freed isn't equal to any of
the other three pointers).  The main advantage is that we never need to
strdup during transaction commit/abort, so cannot cause an out-of-memory
failure there.
@


1.3
log
@
$Header: -> $PostgreSQL Changes ...
@
text
@d1 1
a1 1
$PostgreSQL: /cvsroot/pgsql-server/src/backend/utils/misc/README,v 1.2 2003/07/29 00:03:18 tgl Exp $
d22 2
a23 2
	bool assign_hook(newvalue, bool doit, bool interactive)
where the type of 'newvalue' matches the kind of variable.  This function
d29 12
a40 11
validity of newvalue and not change any derived state.  "interactive" is
true when we are performing a SET command; in this case it is okay for the
assign_hook to raise an error via elog().  If the function returns false
for an interactive assignment then guc.c will report a generic "invalid
value" error message.  (An internal elog() in an assign_hook is only
needed if you want to generate a specialized error message.)  But when
"interactive" is false we are reading a non-interactive option source,
such as postgresql.conf.  In this case the assign_hook should *not* elog
but should just return false if it doesn't like the newvalue.  (An
elog(LOG) call would be acceptable if you feel a need for a custom
complaint in this situation.)
d45 1
a45 1
				bool interactive)
@


1.2
log
@Apply (a somewhat revised version of) Greg Mullane's patch to eliminate
heuristic determination of day vs month in date/time input.  Add the
ability to specify that input is interpreted as yy-mm-dd order (which
formerly worked, but only for yy greater than 31).  DateStyle's input
component now has the preferred spellings DMY, MDY, or YMD; the older
keywords European and US are now aliases for the first two of these.
Per recent discussions on pgsql-general.
@
text
@d1 1
a1 1
$Header: /cvsroot/pgsql-server/src/backend/utils/misc/README,v 1.1 2002/05/17 01:19:18 tgl Exp $
@


1.1
log
@Merge the last few variable.c configuration variables into the generic
GUC support.  It's now possible to set datestyle, timezone, and
client_encoding from postgresql.conf and per-database or per-user
settings.  Also, implement rollback of SET commands that occur in a
transaction that later fails.  Create a SET LOCAL var = value syntax
that sets the variable only for the duration of the current transaction.
All per previous discussions in pghackers.
@
text
@d1 1
a1 1
$Header$
d52 2
a53 2
datestyle always returns a string that includes both basic datestyle and
us/euro option, although the input might have specified only one.
@

