Issue: \ is escaped oddly when displaying the contents of array fields.
Severity: annoyance
Affects: 8.1.3, 8.1.4, 8.0.3, possibly others.
Demonstration of bug:

When saving \ escaped values into text array fields, the \ is escaped when
displaying the contents of the array, leading to an appearance that the
correct data was not saved:

scratch=# create table test_arr ( tarr text[] );
CREATE TABLE
scratch=# insert into test_arr values ( array['x\y','x\\y','x y'] );
INSERT 5695623 1
scratch=# select * from test_arr;
tarr
-------------------
{xy,"x\\y","x y"}
(1 row)

scratch=# select tarr[1] from test_arr;
tarr
------
xy
(1 row)

scratch=# select tarr[2] from test_arr;
tarr
------
x\y
(1 row)

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Josh Berkus wrote:

tarr[1] does not have a \, because it was eaten by the parser (so \y is
the same as a plain y). tarr[2] does have a single backslash, which for
output purposes is shown escaped with another backslash when part of an
array, but unescaped when not. I'm not sure if this qualifies as a bug
or not.

You can pass the array back and it will be valid, but amusingly you must
escape tarr[2] before passing it back.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Alvaro,

I think it does. It's not consistent with how text values not in an array
are displayed. The whole reason I reported it was because of a user
thinking their data wasn't being saved correctly, so it's causing
confusion.

FWIW, I personaly think we should be using the ARRAY[] format for display
anyway, but that would break some backwards compatibility ...

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Josh Berkus <josh (AT) agliodbs (DOT) com> writes:
This is documented behavior for arrays:
http://developer.postgresql.org/docs...s.html#AEN5764
and has been that way for a very long time. If we change it we will
break every array-using application on the planet, because it will
in fact be impossible to parse an array value unambiguously.

I don't think "one user was confused" justifies fooling with this.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Tom,

Ok, so "yes, it's inconsistent, but we don't want to break backwards
compatibility." I can buy that ...

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster