From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: outfuncs.c utility statement support |
Date: | 2017-06-18 01:07:00 |
Message-ID: | 958fca07-838c-07cc-0ab6-1048e37c1372@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6/14/17 12:05, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-06-18 02:31:18 | Re: Decimal64 and Decimal128 |
Previous Message | Piotr Stefaniak | 2017-06-17 23:45:29 | Re: Preliminary results for proposed new pgindent implementation |