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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org>, Kris Jurka <books(at)ejurka(dot)com>
Subject: Re: [PATCHES] [BUGS] casting strings to multidimensional arrays yields strange
Date: 2004-08-07 02:56:49
Message-ID: 25561.1091847409@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers pgsql-patches

Joe Conway <mail(at)joeconway(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Joe Conway 2004-08-07 03:19:35 Re: [PATCHES] [BUGS] casting strings to multidimensional arrays yields
Previous Message Joe Conway 2004-08-07 01:50:01 Re: [PATCHES] [BUGS] casting strings to multidimensional arrays yields

Browse pgsql-hackers by date

  From Date Subject
Next Message John Hansen 2004-08-07 03:04:21 Re: UNICODE characters above 0x10000
Previous Message Marc G. Fournier 2004-08-07 02:08:07 cvsweb down temporarily

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2004-08-07 02:58:54 Re: Autovacuum Integration Patch Take 5
Previous Message Bruce Momjian 2004-08-07 02:15:23 Re: make fails if path has spaces