Re: outfuncs.c utility statement support

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

In response to

Responses

Browse pgsql-hackers by date

  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