On Wednesday 12 March 2008 03:16:27 Martijn van Oosterhout wrote:
> On Tue, Mar 11, 2008 at 12:41:35PM -0400, Tom Lane wrote:
> > > If I create the same function on my computer running PostgreSQL 8.3.0
> > > and try the \df+ then the Source Code shows:
> > >
> > > \x09DECLARE
> > > \x09\x09result text;
> > > ...
> >
> > That's not an encoding problem, that's an intentional behavioral change
> > in the way that psql formats strings for display.
> >
> > I guess it's a bit annoying if you were hoping that tabs would be useful
> > for pretty-printing purposes. Should we reconsider what's done with a
> > tab in mbprint.c?
>
> At the time that patch was introduced there was discussion about this.
> The problem being that psql has no idea what will actually happen to
> the cursor when it emits a tab. You can guess but in the end we decided
> it was more important to have the display not messed up than displaying
> tabs as is.
>
> The other alternative is to convert tabs to spaces on output. Can't
> remember why we didn't do that.
>
> Have a nice day,
I'd like to point out something else. It's one thing to see the tabs as \x09
in \df+ output, but quite another from a select statement. I often find
myself doing something like this: (actually, I usually do "\o |lp" but you
get the idea)
foresite=> \o some.file
foresite=> select errmsg from fserrorlog ;
foresite=> \o
foresite=> \! cat some.file
errmsg
--------------------------
Debugging fssURL:\r
\x09go => 3\r
\x09switchform => \r
I also tried a command-line parameter:
$ psql -h db -U cnie -c "SELECT errmsg FROM fserrorlog" foresite
..with the same result as above. I confess I don't understand the problem
of "what will actually happen to the cursor when it emits a tab" at the level
that you developer folks do, but just wanted to point out that to me as a
user, this behavior looks like an error. My expectations are that a tab be
sent as a tab, not a textual representation of a tab.
