Обсуждение: Handling of \ in array data display

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

Josh Berkus wrote:

> 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[2] from test_arr;
>  tarr
> ------
>  x\y
> (1 row)

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

Alvaro,

> 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.

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

Josh Berkus <josh@agliodbs.com> writes:
>> 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.

> I think it does.

This is documented behavior for arrays:
http://developer.postgresql.org/docs/postgres/arrays.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

Tom,

> This is documented behavior for arrays:
> http://developer.postgresql.org/docs/postgres/arrays.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.

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