Postgres Pro
Downloads
Home   >   mailing lists

Thread: Re: [NOVICE] encoding problems

Re: [NOVICE] encoding problems

From
Tom Lane
Date:
Cliff Nieuwenhuis <cliff@nieusite.com> writes:
> I'm not sure how to ask this question.  I have written a function, and with
> PostgreSQL 8.0.13 I can do a "\df+" and see something like this under Source
> Code:
>     DECLARE
>         result text;
> ...

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

            regards, tom lane

Re: [NOVICE] encoding problems

From
Martijn van Oosterhout
Date:
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,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

Re: [NOVICE] encoding problems

From
Tom Lane
Date:
Martijn van Oosterhout <kleptog@svana.org> writes:
> The other alternative is to convert tabs to spaces on output. Can't
> remember why we didn't do that.

Yeah.  The idea I had was to invent a parameter specifying the number of
spaces a tab should expand to --- setting this to zero would give you
the current \x09 behavior.  I'm not sure how painful it would be to
expand tabs properly in mbprint, but it seems possible.

            regards, tom lane

Re: [NOVICE] encoding problems

From
"Guillaume Smet"
Date:
On Wed, Mar 12, 2008 at 4:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
>  > The other alternative is to convert tabs to spaces on output. Can't
>  > remember why we didn't do that.
>
>  Yeah.  The idea I had was to invent a parameter specifying the number of
>  spaces a tab should expand to --- setting this to zero would give you
>  the current \x09 behavior.  I'm not sure how painful it would be to
>  expand tabs properly in mbprint, but it seems possible.

Is there any plan to fix this behaviour in 8.3 branch? For instance,
the pg_stat_activity output is far less readable than before when
people use tabs to indent the SQL queries in their applications. From
my experience, it's pretty common and it's really a regression from
the usability point of view.

Regards,

-- 
Guillaume