2000-01-19 00:30:24 +01:00
|
|
|
/*
|
|
|
|
* psql - the PostgreSQL interactive terminal
|
|
|
|
*
|
2017-01-03 19:48:53 +01:00
|
|
|
* Copyright (c) 2000-2017, PostgreSQL Global Development Group
|
2000-01-19 00:30:24 +01:00
|
|
|
*
|
Make psql reject attempts to set special variables to invalid values.
Previously, if the user set a special variable such as ECHO to an
unrecognized value, psql would bleat but store the new value anyway, and
then fall back to a default setting for the behavior controlled by the
variable. This was agreed to be a not particularly good idea. With
this patch, invalid values result in an error message and no change in
state.
(But this applies only to variables that affect psql's behavior; purely
informational variables such as ENCODING can still be set to random
values.)
To do this, modify the API for psql's assign-hook functions so that they
can return an OK/not OK result, and give them the responsibility for
printing error messages when they reject a value. Adjust the APIs for
ParseVariableBool and ParseVariableNum to support the new behavior
conveniently.
In passing, document the variable VERSION, which had somehow escaped that.
And improve the quite-inadequate commenting in psql/variables.c.
Daniel Vérité, reviewed by Rahila Syed, some further tweaking by me
Discussion: https://postgr.es/m/7356e741-fa59-4146-a8eb-cf95fd6b21fb@mm
2017-01-30 22:37:15 +01:00
|
|
|
* This implements a sort of variable repository. One could also think of it
|
|
|
|
* as a cheap version of an associative array. Each variable has a string
|
|
|
|
* name and a string value. The value can't be NULL, or more precisely
|
|
|
|
* that's not distinguishable from the variable being unset.
|
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/bin/psql/variables.h
|
2000-01-19 00:30:24 +01:00
|
|
|
*/
|
2006-08-29 17:19:51 +02:00
|
|
|
#ifndef VARIABLES_H
|
|
|
|
#define VARIABLES_H
|
2000-01-19 00:30:24 +01:00
|
|
|
|
|
|
|
/*
|
Make psql reject attempts to set special variables to invalid values.
Previously, if the user set a special variable such as ECHO to an
unrecognized value, psql would bleat but store the new value anyway, and
then fall back to a default setting for the behavior controlled by the
variable. This was agreed to be a not particularly good idea. With
this patch, invalid values result in an error message and no change in
state.
(But this applies only to variables that affect psql's behavior; purely
informational variables such as ENCODING can still be set to random
values.)
To do this, modify the API for psql's assign-hook functions so that they
can return an OK/not OK result, and give them the responsibility for
printing error messages when they reject a value. Adjust the APIs for
ParseVariableBool and ParseVariableNum to support the new behavior
conveniently.
In passing, document the variable VERSION, which had somehow escaped that.
And improve the quite-inadequate commenting in psql/variables.c.
Daniel Vérité, reviewed by Rahila Syed, some further tweaking by me
Discussion: https://postgr.es/m/7356e741-fa59-4146-a8eb-cf95fd6b21fb@mm
2017-01-30 22:37:15 +01:00
|
|
|
* Variables can be given "assign hook" functions. The assign hook can
|
|
|
|
* prevent invalid values from being assigned, and can update internal C
|
|
|
|
* variables to keep them in sync with the variable's current value.
|
|
|
|
*
|
|
|
|
* A hook function is called before any attempted assignment, with the
|
|
|
|
* proposed new value of the variable (or with NULL, if an \unset is being
|
|
|
|
* attempted). If it returns false, the assignment doesn't occur --- it
|
|
|
|
* should print an error message with psql_error() to tell the user why.
|
2006-08-29 17:19:51 +02:00
|
|
|
*
|
Make psql reject attempts to set special variables to invalid values.
Previously, if the user set a special variable such as ECHO to an
unrecognized value, psql would bleat but store the new value anyway, and
then fall back to a default setting for the behavior controlled by the
variable. This was agreed to be a not particularly good idea. With
this patch, invalid values result in an error message and no change in
state.
(But this applies only to variables that affect psql's behavior; purely
informational variables such as ENCODING can still be set to random
values.)
To do this, modify the API for psql's assign-hook functions so that they
can return an OK/not OK result, and give them the responsibility for
printing error messages when they reject a value. Adjust the APIs for
ParseVariableBool and ParseVariableNum to support the new behavior
conveniently.
In passing, document the variable VERSION, which had somehow escaped that.
And improve the quite-inadequate commenting in psql/variables.c.
Daniel Vérité, reviewed by Rahila Syed, some further tweaking by me
Discussion: https://postgr.es/m/7356e741-fa59-4146-a8eb-cf95fd6b21fb@mm
2017-01-30 22:37:15 +01:00
|
|
|
* When a hook function is installed with SetVariableAssignHook(), it is
|
|
|
|
* called with the variable's current value (or with NULL, if it wasn't set
|
|
|
|
* yet). But its return value is ignored in this case. The hook should be
|
|
|
|
* set before any possibly-invalid value can be assigned.
|
|
|
|
*/
|
|
|
|
typedef bool (*VariableAssignHook) (const char *newval);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Data structure representing one variable.
|
2006-08-29 17:19:51 +02:00
|
|
|
*
|
|
|
|
* Note: if value == NULL then the variable is logically unset, but we are
|
|
|
|
* keeping the struct around so as not to forget about its hook function.
|
1999-11-04 22:56:02 +01:00
|
|
|
*/
|
1999-11-05 00:14:30 +01:00
|
|
|
struct _variable
|
|
|
|
{
|
|
|
|
char *name;
|
|
|
|
char *value;
|
2006-08-29 17:19:51 +02:00
|
|
|
VariableAssignHook assign_hook;
|
1999-11-05 00:14:30 +01:00
|
|
|
struct _variable *next;
|
1999-11-04 22:56:02 +01:00
|
|
|
};
|
|
|
|
|
Make psql reject attempts to set special variables to invalid values.
Previously, if the user set a special variable such as ECHO to an
unrecognized value, psql would bleat but store the new value anyway, and
then fall back to a default setting for the behavior controlled by the
variable. This was agreed to be a not particularly good idea. With
this patch, invalid values result in an error message and no change in
state.
(But this applies only to variables that affect psql's behavior; purely
informational variables such as ENCODING can still be set to random
values.)
To do this, modify the API for psql's assign-hook functions so that they
can return an OK/not OK result, and give them the responsibility for
printing error messages when they reject a value. Adjust the APIs for
ParseVariableBool and ParseVariableNum to support the new behavior
conveniently.
In passing, document the variable VERSION, which had somehow escaped that.
And improve the quite-inadequate commenting in psql/variables.c.
Daniel Vérité, reviewed by Rahila Syed, some further tweaking by me
Discussion: https://postgr.es/m/7356e741-fa59-4146-a8eb-cf95fd6b21fb@mm
2017-01-30 22:37:15 +01:00
|
|
|
/* Data structure representing a set of variables */
|
1999-11-05 00:14:30 +01:00
|
|
|
typedef struct _variable *VariableSpace;
|
1999-11-04 22:56:02 +01:00
|
|
|
|
Make psql reject attempts to set special variables to invalid values.
Previously, if the user set a special variable such as ECHO to an
unrecognized value, psql would bleat but store the new value anyway, and
then fall back to a default setting for the behavior controlled by the
variable. This was agreed to be a not particularly good idea. With
this patch, invalid values result in an error message and no change in
state.
(But this applies only to variables that affect psql's behavior; purely
informational variables such as ENCODING can still be set to random
values.)
To do this, modify the API for psql's assign-hook functions so that they
can return an OK/not OK result, and give them the responsibility for
printing error messages when they reject a value. Adjust the APIs for
ParseVariableBool and ParseVariableNum to support the new behavior
conveniently.
In passing, document the variable VERSION, which had somehow escaped that.
And improve the quite-inadequate commenting in psql/variables.c.
Daniel Vérité, reviewed by Rahila Syed, some further tweaking by me
Discussion: https://postgr.es/m/7356e741-fa59-4146-a8eb-cf95fd6b21fb@mm
2017-01-30 22:37:15 +01:00
|
|
|
|
1999-11-04 22:56:02 +01:00
|
|
|
VariableSpace CreateVariableSpace(void);
|
1999-11-05 00:14:30 +01:00
|
|
|
const char *GetVariable(VariableSpace space, const char *name);
|
2003-03-20 07:43:35 +01:00
|
|
|
|
Make psql reject attempts to set special variables to invalid values.
Previously, if the user set a special variable such as ECHO to an
unrecognized value, psql would bleat but store the new value anyway, and
then fall back to a default setting for the behavior controlled by the
variable. This was agreed to be a not particularly good idea. With
this patch, invalid values result in an error message and no change in
state.
(But this applies only to variables that affect psql's behavior; purely
informational variables such as ENCODING can still be set to random
values.)
To do this, modify the API for psql's assign-hook functions so that they
can return an OK/not OK result, and give them the responsibility for
printing error messages when they reject a value. Adjust the APIs for
ParseVariableBool and ParseVariableNum to support the new behavior
conveniently.
In passing, document the variable VERSION, which had somehow escaped that.
And improve the quite-inadequate commenting in psql/variables.c.
Daniel Vérité, reviewed by Rahila Syed, some further tweaking by me
Discussion: https://postgr.es/m/7356e741-fa59-4146-a8eb-cf95fd6b21fb@mm
2017-01-30 22:37:15 +01:00
|
|
|
bool ParseVariableBool(const char *value, const char *name,
|
|
|
|
bool *result);
|
|
|
|
|
|
|
|
bool ParseVariableNum(const char *value, const char *name,
|
|
|
|
int *result);
|
|
|
|
|
2003-08-04 02:43:34 +02:00
|
|
|
int GetVariableNum(VariableSpace space,
|
2006-08-29 17:19:51 +02:00
|
|
|
const char *name,
|
2003-08-04 02:43:34 +02:00
|
|
|
int defaultval,
|
Make psql reject attempts to set special variables to invalid values.
Previously, if the user set a special variable such as ECHO to an
unrecognized value, psql would bleat but store the new value anyway, and
then fall back to a default setting for the behavior controlled by the
variable. This was agreed to be a not particularly good idea. With
this patch, invalid values result in an error message and no change in
state.
(But this applies only to variables that affect psql's behavior; purely
informational variables such as ENCODING can still be set to random
values.)
To do this, modify the API for psql's assign-hook functions so that they
can return an OK/not OK result, and give them the responsibility for
printing error messages when they reject a value. Adjust the APIs for
ParseVariableBool and ParseVariableNum to support the new behavior
conveniently.
In passing, document the variable VERSION, which had somehow escaped that.
And improve the quite-inadequate commenting in psql/variables.c.
Daniel Vérité, reviewed by Rahila Syed, some further tweaking by me
Discussion: https://postgr.es/m/7356e741-fa59-4146-a8eb-cf95fd6b21fb@mm
2017-01-30 22:37:15 +01:00
|
|
|
int faultval);
|
2003-03-20 07:43:35 +01:00
|
|
|
|
2003-08-04 02:43:34 +02:00
|
|
|
void PrintVariables(VariableSpace space);
|
2003-03-20 07:43:35 +01:00
|
|
|
|
2003-08-04 02:43:34 +02:00
|
|
|
bool SetVariable(VariableSpace space, const char *name, const char *value);
|
Make psql reject attempts to set special variables to invalid values.
Previously, if the user set a special variable such as ECHO to an
unrecognized value, psql would bleat but store the new value anyway, and
then fall back to a default setting for the behavior controlled by the
variable. This was agreed to be a not particularly good idea. With
this patch, invalid values result in an error message and no change in
state.
(But this applies only to variables that affect psql's behavior; purely
informational variables such as ENCODING can still be set to random
values.)
To do this, modify the API for psql's assign-hook functions so that they
can return an OK/not OK result, and give them the responsibility for
printing error messages when they reject a value. Adjust the APIs for
ParseVariableBool and ParseVariableNum to support the new behavior
conveniently.
In passing, document the variable VERSION, which had somehow escaped that.
And improve the quite-inadequate commenting in psql/variables.c.
Daniel Vérité, reviewed by Rahila Syed, some further tweaking by me
Discussion: https://postgr.es/m/7356e741-fa59-4146-a8eb-cf95fd6b21fb@mm
2017-01-30 22:37:15 +01:00
|
|
|
void SetVariableAssignHook(VariableSpace space, const char *name, VariableAssignHook hook);
|
2003-08-04 02:43:34 +02:00
|
|
|
bool SetVariableBool(VariableSpace space, const char *name);
|
|
|
|
bool DeleteVariable(VariableSpace space, const char *name);
|
1999-11-04 22:56:02 +01:00
|
|
|
|
Make psql reject attempts to set special variables to invalid values.
Previously, if the user set a special variable such as ECHO to an
unrecognized value, psql would bleat but store the new value anyway, and
then fall back to a default setting for the behavior controlled by the
variable. This was agreed to be a not particularly good idea. With
this patch, invalid values result in an error message and no change in
state.
(But this applies only to variables that affect psql's behavior; purely
informational variables such as ENCODING can still be set to random
values.)
To do this, modify the API for psql's assign-hook functions so that they
can return an OK/not OK result, and give them the responsibility for
printing error messages when they reject a value. Adjust the APIs for
ParseVariableBool and ParseVariableNum to support the new behavior
conveniently.
In passing, document the variable VERSION, which had somehow escaped that.
And improve the quite-inadequate commenting in psql/variables.c.
Daniel Vérité, reviewed by Rahila Syed, some further tweaking by me
Discussion: https://postgr.es/m/7356e741-fa59-4146-a8eb-cf95fd6b21fb@mm
2017-01-30 22:37:15 +01:00
|
|
|
void PsqlVarEnumError(const char *name, const char *value, const char *suggestions);
|
|
|
|
|
2001-11-05 18:46:40 +01:00
|
|
|
#endif /* VARIABLES_H */
|