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