Joe Conway <[EMAIL PROTECTED]> writes: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?
Well, '{}' is a special case representing an empty array. One of the characteristics of an empty array is that is has 0 dimensions. An empty array can later be treated as an array of any dimension, e.g.:
regression=# select '{}'::int[] || ARRAY[1]; ?column? ---------- {1} (1 row)
regression=# select '{}'::int[] || ARRAY[[1]]; ?column? ---------- {{1}} (1 row)
In my mind, '{{},{}}' clearly defines a two dimensional array, and therefore needs elements, which in this case would have to be NULL (or empty strings -- see below). Once we can deal with NULL elements, I'd think '{{},{}}' ought to be accepted, and produce a 2d array with 2 NULL elements. Note how this works in 7.4:
select '{{},{}}'::text[]; text ------------- {{""},{""}} (1 row)
I thought creation of empty strings was what we agreed the other day to eliminate?
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.
I know is has accepted this, but I always found it surprising and strange. And I believe we've had others complain about this behavior. It seems to me that if you are going to the trouble to quote the item, why would you want random garbage outside the quotes to get magically appended?
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.
Ah, thanks for the explanation. I'll fix that too.
Thanks,
Joe
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html