Joe Conway <mail@joeconway.com> writes:
> The attached patch suppresses trailing whitespace, but allows embedded
> whitespace in unquoted elements as discussed above. It also rejects some
> previously accepted cases that were just too strange to be correct:
> -- Postgres 8.0, with the patch
> -- none of these should be accepted
> select '{{1,{2}},{2,3}}'::text[];
> ERROR: malformed array literal: "{{1,{2}},{2,3}}"
Okay, uneven nesting level of {} is clearly bogus.
> select '{{},{}}'::text[];
> ERROR: malformed array literal: "{{},{}}"
Hm. This seems like it would be a legitimate representation of a 2x0
array. Why would you allow '{}' and reject this?
> select '{{1,2},\\{2,3}}'::text[];
> ERROR: malformed array literal: "{{1,2},\{2,3}}"
Okay, junk outside the {} structure is bad.
> select '{{"1 2" x},{3}}'::text[];
> ERROR: malformed array literal: "{{"1 2" x},{3}}"
So here you're rejecting the first data value because it's partially
quoted and partially not? I guess this is arguably reasonable, but
I'm not sure that it's really necessary either. Historically array_in
has taken this sort of thing.
> The third case above actually does get an ERROR in 7.4 but it looks
> suspicious itself:
> select '{{1,2},\\{2,3}}'::text[];
> ERROR: malformed array literal: "{{1"
This is something I was planning to fix myself: ReadArrayStr is using
arrayStr as the string to complain about in its error messages, but that
is the same string that it is scribbling on by overwriting with \0 where
it wants to terminate an individual data value. So you get bogus
messages anytime a syntax error is detected after having absorbed at
least one item value.
The easiest way to fix it seems to be for array_in to pass an additional
parameter which is the original non-overwritable input string, and use
that in the ereport calls.
> More examples:
These look okay. Didn't study the code though.
regards, tom lane