Thread: character varying array bug in 7.4.1
Could someone tell me if this bug is trivially reproducible or already solv=
ed before I do a lot of needless documentation on it?
I upgraded from 7.1beta5 to 7.4.1 recently, and I noticed that many of my c=
haracter varying arrays were getting a trailing space inserted into their l=
ast value. This appears to be the result of white space being misplaced dur=
ing the INSERT/UPDATE command. If there is a space before the close-curly-b=
race, it gets appended to the last quoted value. When there is no space bet=
ween the close-quotes and the close-curly-brace, the correct value is inser=
ted. This behavior did not occur in 7.1beta5.
Here's a test I did to show the problem:
test=3D> update nametable set names =3D '{ "arf" }' where id =3D 1;
UPDATE 1
golem=3D> select id, names from nametable where id =3D 1;
id | names=20
----+------------------
1 | {"arf "}
(1 row)
golem=3D> update nametable set names =3D '{"arf"}' where id =3D 1;
UPDATE 1
golem=3D> select id, names from nametable where id =3D 1;
id | names=20
----+------------------
1 | {arf}
(1 row)
I'll be glad to document this further if needed.
---
Andrew C. Esh mail:Andrew_Esh[at]adaptec.com
Adaptec, Inc.
2905 Northwest Blvd., Suite 20 763-557-9005 (main)
Plymouth, MN 55441-2644 USA 763-551-6418 (direct)
I was able to do this test on a platform running 7.3.2, and the result is t=
he same as version 7.4.1, so if this is a bug, it is also in version 7.3.2.
-----Original Message-----
From: pgsql-bugs-owner@postgresql.org
[mailto:pgsql-bugs-owner@postgresql.org]On Behalf Of Esh, Andrew
Sent: Thursday, January 08, 2004 12:53 PM
To: pgsql-bugs@postgresql.org
Subject: [BUGS] character varying array bug in 7.4.1
Could someone tell me if this bug is trivially reproducible or already solv=
ed before I do a lot of needless documentation on it?
I upgraded from 7.1beta5 to 7.4.1 recently, and I noticed that many of my c=
haracter varying arrays were getting a trailing space inserted into their l=
ast value. This appears to be the result of white space being misplaced dur=
ing the INSERT/UPDATE command. If there is a space before the close-curly-b=
race, it gets appended to the last quoted value. When there is no space bet=
ween the close-quotes and the close-curly-brace, the correct value is inser=
ted. This behavior did not occur in 7.1beta5.
Here's a test I did to show the problem:
test=3D> update nametable set names =3D '{ "arf" }' where id =3D 1;
UPDATE 1
golem=3D> select id, names from nametable where id =3D 1;
id | names=20
----+------------------
1 | {"arf "}
(1 row)
golem=3D> update nametable set names =3D '{"arf"}' where id =3D 1;
UPDATE 1
golem=3D> select id, names from nametable where id =3D 1;
id | names=20
----+------------------
1 | {arf}
(1 row)
I'll be glad to document this further if needed.
---
Andrew C. Esh mail:Andrew_Esh[at]adaptec.com
Adaptec, Inc.
2905 Northwest Blvd., Suite 20 763-557-9005 (main)
Plymouth, MN 55441-2644 USA 763-551-6418 (direct)
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
"Esh, Andrew" <Andrew_Esh@adaptec.com> writes:
> I upgraded from 7.1beta5 to 7.4.1 recently, and I noticed that many of
> my character varying arrays were getting a trailing space inserted
> into their last value. This appears to be the result of white space
> being misplaced during the INSERT/UPDATE command. If there is a space
> before the close-curly-brace, it gets appended to the last quoted
> value.
It's been that way since 7.2, and was intentional. IIRC, the array
parser's behavior in 7.1 and before was inconsistent across datatypes,
and we concluded this was the closest we could get to backwards
compatibility while still having something moderately sane. It is
documented:
You may write whitespace before a left brace, after a right
brace, or before any individual item string. Whitespace after an
item is not ignored, however: after skipping leading whitespace,
everything up to the next right brace or delimiter is taken as
the item value.
See http://www.postgresql.org/docs/7.4/static/arrays.html#AEN5228
regards, tom lane