Handling of \ in array data display

Started by Josh Berkusover 19 years ago5 messagesbugs
Jump to latest
#1Josh Berkus
josh@agliodbs.com

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

#2Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Josh Berkus (#1)
Re: Handling of \ in array data display

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

#3Josh Berkus
josh@agliodbs.com
In reply to: Alvaro Herrera (#2)
Re: Handling of \ in array data display

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

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Josh Berkus (#3)
Re: Handling of \ in array data display

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

#5Josh Berkus
josh@agliodbs.com
In reply to: Tom Lane (#4)
Re: Handling of \ in array data display

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