Re: [PATCHES] [BUGS] casting strings to multidimensional arrays yields

Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> 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