Re: postgres 7.2.1 parse bug - Mailing list pgsql-general

From Tom Lane
Subject Re: postgres 7.2.1 parse bug
Date
Msg-id 2056.1028040095@sss.pgh.pa.us
Whole thread Raw
In response to postgres 7.2.1 parse bug  (Amin Abdulghani <amin@quantiva.com>)
Responses Re: postgres 7.2.1 parse bug  (Amin Abdulghani <amin@quantiva.com>)
List pgsql-general
Amin Abdulghani <amin@quantiva.com> writes:
> Apparently there seems to be a parsing bug in 7.2.1 (
> though it seems to be OK in 7.2)when inserting into array
> columns. The bug seems to be that if an
> array element is quoted with "" followed by spaces before
> the comma (for the next element), the extra space becomes
> part of the text for the element.

I do not believe this is a bug.  The old behavior was quite buggy
though.  Consider for example
    insert into testa values('{"bob" ,"moo","x"yz,"","theend"}');
7.1 and before would produce "x" as the third array element value,
losing anything to the right of the second double-quote.  7.2 produces
"xyz" which seems a more natural interpretation.  What's even stranger
is
    insert into testa values('{"bob" ,"moo",ab"x"yz,"","theend"}');
7.2 produces "abxyz", where prior versions produced "x".

You might say "we ignore leading whitespace in an array element, why
not trailing whitespace too"?  Well, we could do that, but I'm afraid
of breaking applications.  Historically trailing whitespace has not
been ignored --- try
    insert into testa values('{"bob" ,"moo", abc  ,"","theend"}');
which produces "abc  " in all versions.

The array parser still has a lot of strange behaviors (it doesn't
work quite right on non-rectangular inputs, for example) but I haven't
had time to work more on it.

            regards, tom lane

pgsql-general by date:

Previous
From: Andrew Sullivan
Date:
Subject: Re: Importing data
Next
From: Andrew Sullivan
Date:
Subject: Re: log sql?