Re: [HACKERS] outfuncs.c utility statement support

2017-07-05 Thread Peter Eisentraut
On 6/21/17 23:40, Tom Lane wrote: > Peter Eisentraut writes: >> On 6/18/17 10:14, Tom Lane wrote: >>> Doesn't cope with backslash-quoted characters. If we're going to bother >>> to do anything here, I think we ought to make it reversible for all >>> possible

Re: [HACKERS] outfuncs.c utility statement support

2017-06-21 Thread Tom Lane
Peter Eisentraut writes: > On 6/18/17 10:14, Tom Lane wrote: >> Doesn't cope with backslash-quoted characters. If we're going to bother >> to do anything here, I think we ought to make it reversible for all >> possible characters. > Makes sense. Updated patch

Re: [HACKERS] outfuncs.c utility statement support

2017-06-21 Thread Peter Eisentraut
On 6/18/17 10:14, Tom Lane wrote: > pg_strtok recognizes "<>" and returns length = 0, so debackslash() > would produce the right answer AFAICS (admittedly, I haven't tested). > But I don't really want to do it like that because of the wasted > palloc space and cycles. > >> Maybe >>

Re: [HACKERS] outfuncs.c utility statement support

2017-06-18 Thread Tom Lane
Peter Eisentraut writes: > An empty token produces "<>", so just debackslashing wouldn't work. pg_strtok recognizes "<>" and returns length = 0, so debackslash() would produce the right answer AFAICS (admittedly, I haven't tested). But I don't really want to do

Re: [HACKERS] outfuncs.c utility statement support

2017-06-17 Thread Peter Eisentraut
On 6/14/17 12:05, Tom Lane wrote: > Peter Eisentraut 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

Re: [HACKERS] outfuncs.c utility statement support

2017-06-14 Thread Tom Lane
Peter Eisentraut 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

Re: [HACKERS] outfuncs.c utility statement support

2017-06-14 Thread Robert Haas
On Tue, Jun 13, 2017 at 11:59 PM, Amit Langote wrote: >> 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

Re: [HACKERS] outfuncs.c utility statement support

2017-06-13 Thread Amit Langote
On 2017/06/14 12:49, Peter Eisentraut wrote: > On 6/13/17 11:25, Peter Eisentraut wrote: >> Running with --debug-print-parse=on, executing >> >> create table test1 (a int, b text); >> >> gives output that is truncated somewhere in the middle (possibly a null >> byte) > > So this seems to be a

Re: [HACKERS] outfuncs.c utility statement support

2017-06-13 Thread Peter Eisentraut
On 6/13/17 11:25, Peter Eisentraut wrote: > Running with --debug-print-parse=on, executing > > create table test1 (a int, b text); > > gives output that is truncated somewhere in the middle (possibly a null > byte) So this seems to be a pretty basic bug. Some node fields of type char may be

Re: [HACKERS] outfuncs.c utility statement support

2017-06-13 Thread Tom Lane
Peter Eisentraut writes: > While debugging some other stuff, I was wondering to what extent node > types supporting utility statements should be supported in outfuncs.c. We've largely not tried too hard in that department. From a debugging standpoint it'd be

[HACKERS] outfuncs.c utility statement support

2017-06-13 Thread Peter Eisentraut
While debugging some other stuff, I was wondering to what extent node types supporting utility statements should be supported in outfuncs.c. Running with --debug-print-parse=on, executing create table test1 (a int, b text); gives output that is truncated somewhere in the middle (possibly a null