Re: outfuncs.c utility statement support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: outfuncs.c utility statement support
Date: 2017-06-14 16:05:05
Message-ID: 31001.1497456305@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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]

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-06-14 17:13:35 Re: A bug in mapping attributes in ATExecAttachPartition()
Previous Message Bruce Momjian 2017-06-14 15:57:59 Re: WIP: Data at rest encryption