database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-02 09:02:37 +03:00
Code Activity

Further fixes for quoted-list GUC values in pg_dump and ruleutils.c.

Browse Source 
Commits 742869946 et al turn out to be a couple bricks shy of a load.
We were dumping the stored values of GUC_LIST_QUOTE variables as they
appear in proconfig or setconfig catalog columns.  However, although that
quoting rule looks a lot like SQL-identifier double quotes, there are two
critical differences: empty strings ("") are legal, and depending on which
variable you're considering, values longer than NAMEDATALEN might be valid
too.  So the current technique fails altogether on empty-string list
entries (as reported by Steven Winfield in bug #15248) and it also risks
truncating file pathnames during dump/reload of GUC values that are lists
of pathnames.

To fix, split the stored value without any downcasing or truncation,
and then emit each element as a SQL string literal.

This is a tad annoying, because we now have three copies of the
comma-separated-string splitting logic in varlena.c as well as a fourth
one in dumputils.c.  (Not to mention the randomly-different-from-those
splitting logic in libpq...)  I looked at unifying these, but it would
be rather a mess unless we're willing to tweak the API definitions of
SplitIdentifierString, SplitDirectoriesString, or both.  That might be
worth doing in future; but it seems pretty unsafe for a back-patched
bug fix, so for now accept the duplication.

Back-patch to all supported branches, as the previous fix was.

Discussion: https://postgr.es/m/7585.1529435872@sss.pgh.pa.us
This commit is contained in:
Tom Lane
2018-07-31 13:00:07 -04:00
parent 23ca82d7ef
commit f3eb76b399
8 changed files with 326 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

37
src/backend/utils/adt/ruleutils.c
View File

@ -2640,14 +2640,39 @@ pg_get_functiondef(PG_FUNCTION_ARGS)
/*
* Variables that are marked GUC_LIST_QUOTE were already fully
* quoted by flatten_set_variable_args() before they were put
* into the proconfig array; we mustn't re-quote them or we'll
* make a mess. Variables that are not so marked should just
* be emitted as simple string literals. If the variable is
* not known to guc.c, we'll do the latter; this makes it
* unsafe to use GUC_LIST_QUOTE for extension variables.
* into the proconfig array. However, because the quoting
* rules used there aren't exactly like SQL's, we have to
* break the list value apart and then quote the elements as
* string literals. (The elements may be double-quoted as-is,
* but we can't just feed them to the SQL parser; it would do
* the wrong thing with elements that are zero-length or
* longer than NAMEDATALEN.)
*
* Variables that are not so marked should just be emitted as
* simple string literals. If the variable is not known to
* guc.c, we'll do that; this makes it unsafe to use
* GUC_LIST_QUOTE for extension variables.
*/
if (GetConfigOptionFlags(configitem, true) & GUC_LIST_QUOTE)
appendStringInfoString(&buf, pos);
{
List *namelist;
ListCell *lc;
/* Parse string into list of identifiers */
if (!SplitGUCList(pos, ',', &namelist))
{
/* this shouldn't fail really */
elog(ERROR, "invalid list syntax in proconfig item");
}
foreach(lc, namelist)
{
char *curname = (char *) lfirst(lc);
simple_quote_literal(&buf, curname);
if (lnext(lc))
appendStringInfoString(&buf, ", ");
}
}
else
simple_quote_literal(&buf, pos);
appendStringInfoChar(&buf, '\n');