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
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
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
>>
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
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
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
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
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
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
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
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
11 matches
Mail list logo