Thread: postgres 7.2.1 parse bug

postgres 7.2.1 parse bug

From
Amin Abdulghani
Date:
Hi,

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.

As an example consider the following (testa is a table
with
a single column data of type text[])
(Note the space after bob and space after the first null
string.)

netwait_db=# insert into testa values('{"bob" ,"moo",""
,"","theend"}');
INSERT 22317950 1
netwait_db=# insert into testa
values('{"Bob","moo","","","theend"}');
INSERT 22317953 1
netwait_db=# select * from testa;
              data
----------------------------
   {"bob ",moo," ","",theend}
   {Bob,moo,"","",theend}
(2 rows)

netwait_db=#


Thanks..
Amin

Re: postgres 7.2.1 parse bug

From
Amin Abdulghani
Date:
Hi,

We use  Postgres extensively for our applications
and it works great for us. Recently we have hit an
array  bug ( at least to us it seems like a bug :) )
  posted down. The bug appears to have
been introduced in 7.2.1. Our applications use array
columns extensively, so its of concern to us. We want to
make sure this bug hasn't compromised other parts of the
array code. Would it be correct to assume that this
is isolated and that the rest of the array code remains
stable?


Thanks..
Amin
On Thu, 25 Jul 2002 16:01:00 -0400
  Amin Abdulghani<amin@quantiva.com> wrote:
>Hi,
>
>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.
>
>As an example consider the following (testa is a table
>with
>a single column data of type text[])
>(Note the space after bob and space after the first null
>string.)
>
>netwait_db=# insert into testa values('{"bob" ,"moo",""
>,"","theend"}');
>INSERT 22317950 1
>netwait_db=# insert into testa
>values('{"Bob","moo","","","theend"}');
>INSERT 22317953 1
>netwait_db=# select * from testa;
>              data
>----------------------------
>   {"bob ",moo," ","",theend}
>   {Bob,moo,"","",theend}
>(2 rows)
>
>netwait_db=#
>
>Thanks..
>Amin


Re: postgres 7.2.1 parse bug

From
Tom Lane
Date:
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

Re: postgres 7.2.1 parse bug

From
Amin Abdulghani
Date:
Was the "new behavior" introduced in 7.2 or 7.2.1? For
me it seems effective 7.2.1. 7.2 seems to go with the
old one. So in 7.2:.
  insert into testa values ('{"bob"
,"moo",ab"x"yz,"","theend"}');

produces x as the third array element and its in 7.2.1
its abxyz.

Thanks..
Amin

On Tue, 30 Jul 2002 10:41:35 -0400
  Tom Lane <tgl@sss.pgh.pa.us> wrote:
>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
>
>---------------------------(end of
>broadcast)---------------------------
>TIP 2: you can get off all lists at once with the
>unregister command
>     (send "unregister YourEmailAddressHere" to
>majordomo@postgresql.org)


Re: postgres 7.2.1 parse bug

From
Tom Lane
Date:
Amin Abdulghani <amin@quantiva.com> writes:
> Was the "new behavior" introduced in 7.2 or 7.2.1? For
> me it seems effective 7.2.1.

Could be.  I don't have a 7.2 handy to check.

            regards, tom lane