Re: [HACKERS] outfuncs.c utility statement support

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] outfuncs.c utility statement support
Дата
Msg-id 31001.1497456305@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] outfuncs.c utility statement support  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: [HACKERS] outfuncs.c utility statement support  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> So this seems to be a pretty basic bug.  Some node fields of type char
> may be zero, and so printing them as a zero byte just truncates the
> whole output string.  This could be fixed by printing chars like strings
> with the full escaping mechanism.  See attached patch.

+1 for fixing this, but you have not handled the read side correctly.
pg_strtok doesn't promise to return a null-terminated string, so without
changes, readfuncs.c would not successfully decode a zero-byte char field.
Also it would do the wrong thing for any character code that outToken had
decided to prefix with a backslash.  I think you could fix both problems
like this:
/* Read a char field (ie, one ascii character) */#define READ_CHAR_FIELD(fldname) \    token = pg_strtok(&length);
 /* skip :fldname */ \    token = pg_strtok(&length);        /* get field value */ \ 
-    local_node->fldname = token[0]
+    local_node->fldname = debackslash(token, length)[0]

although that's annoyingly expensive for the normal case where no
special processing is needed.  Maybe better

+    local_node->fldname = (length == 0) ? '\0' : (token[0] == '\\') ? token[1] : token[0]
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] WIP: Data at rest encryption
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()