On 6/14/17 12:05, Tom Lane wrote: > Peter Eisentraut <peter.eisentr...@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]
An empty token produces "<>", so just debackslashing wouldn't work. Maybe local_node->fldname = length ? token[0] : '\0'; ? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
