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
|
Список | 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 по дате отправления: