Обсуждение: 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