Обсуждение: Questions about proper newline handling in psql output

Поиск
Список
Период
Сортировка

Questions about proper newline handling in psql output

От
Martijn van Oosterhout
Дата:
Hi,

I basically have a functional version for aligned output, examples at
the bottom of this email. It handles multiline data values and
multiline headers. However, there are some areas where I could use some
input.

1. To be able to control the spacing, psql now has to be very careful
about its output. eg \r is printed as \r, ascii control characters are
output as \x00 style and other control chars as \u0000. This is a
change from previous behaviour, yet you're pretty much forced to if you
want to control the output.

Is this change acceptable?

2. Currently I've changed the aligned outputs but not the unaligned
ones. Given you're not worrying about alignment there anyway, why do
the work? Also, we recommend unaligned output for script users so I
don't feel right changing it.

Is this distinction acceptable?

3. How to show that a value is continued? As you can see below I use
':' before columns that have data. This obviously doesn't work for
first column if there's no outer border. If your border style is 0
you're totally out of luck.

I remember a discussion on this before but couldn't find it in the
archives. Either a reference or some other hints would be appreciated.

4. Some system output like pg_views has really really long strings,
would it be acceptable to change the output there to add newlines at
various places to make it output nicer with this change?

5. Auto string folding. If a string is really long, fold it so it fits
in a screen width, perhaps with '\' continuation. I havn't done this
but I can imagine some people (including me) would love it.

6. Currently I've implemented support for UTF-8 and all ASCII
compatable single-byte encodings. Given that psql didn't support the
others anyway maybe no-one cares, but I have to ask: does anyone care?
If so, I need info on *how* to support an encoding.

Thanks for your attention. See you tomorrow.

Query is: select oid, prosrc as "HdrLine1
HdrLine2", proacl from pg_proc limit 1;

Border style is 1. oid  |                              HdrLine1                               | proacl       |
                   HdrLine2                               |         
-------+---------------------------------------------------------------------+--------17009 | select 1 union all select
2union all select 3 union all            |             :         select 4 union all select 5 union all select 6 union
all                 :         select 7 union all select 8 union all select 9 union all                  :
select10 union all select 11 union all select 12 union all               :         select 13 union all select 14 union
allselect 15 union all               :         select 16 union all select 17 union all select 18 union all
:         select 19 union all select 20 union all select 21 union all               :         select 22 union all
select23 union all select 24 union all               :         select 25 union all select 26 union all select 27 union
all              :         select 28 union all select 29 union all select 30 union all               :         select
31union all select 32                                        
(1 row)

Expanded display is on.
-[ RECORD 1 ]-----------------------------------------------------------------
oid      | 17009
HdrLine1 | select 1 union all select 2 union all select 3 union all
HdrLine2 :         select 4 union all select 5 union all select 6 union all        :         select 7 union all select
8union all select 9 union all        :         select 10 union all select 11 union all select 12 union all        :
   select 13 union all select 14 union all select 15 union all        :         select 16 union all select 17 union all
select18 union all        :         select 19 union all select 20 union all select 21 union all        :         select
22union all select 23 union all select 24 union all        :         select 25 union all select 26 union all select 27
unionall        :         select 28 union all select 29 union all select 30 union all        :         select 31 union
allselect 32 
proacl   |

# select chr(8);chr
------\x08
(1 row)


--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Re: Questions about proper newline handling in psql output

От
"Greg Sabino Mullane"
Дата:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> 3. How to show that a value is continued? As you can see below I use
>...
> I remember a discussion on this before but couldn't find it in the
> archives. Either a reference or some other hints would be appreciated.

I think we liked the "+" character.

> 4. Some system output like pg_views has really really long strings,
> would it be acceptable to change the output there to add newlines at
> various places to make it output nicer with this change?

I'd say no, until you propose a more concrete set of rules on how and when.

> 5. Auto string folding. If a string is really long, fold it so it fits
> in a screen width, perhaps with '\' continuation. I havn't done this
> but I can imagine some people (including me) would love it.

Sounds good to me.

> Query is: select oid, prosrc as "HdrLine1 HdrLine2", proacl from pg_proc limit 1;

Some smaller samples with a third column (and a large 2nd one) might be nice.

Thanks for tackling this, it should be a nice improvement.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200509262011
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iD8DBQFDOI5OvJuQZxSWSsgRAoiZAJ4sNyNMFE5+xiA+uDlRnWZA03cbmACfWv67
lFKR/iwZnkp7mb0BvLLFkkk=
=L9nw
-----END PGP SIGNATURE-----




Re: Questions about proper newline handling in psql output

От
Peter Eisentraut
Дата:
Am Sonntag, 25. September 2005 22:45 schrieb Martijn van Oosterhout:
> 1. To be able to control the spacing, psql now has to be very careful
> about its output. eg \r is printed as \r, ascii control characters are
> output as \x00 style and other control chars as \u0000. This is a
> change from previous behaviour, yet you're pretty much forced to if you
> want to control the output.

I don't think this is necessary.  If you put control characters into your 
text, then you clearly don't care about aligned output, so you don't get any.  
About \r, I think that needs to be figured into the alignment calculation, to 
work well on Windows and Mac.

> 2. Currently I've changed the aligned outputs but not the unaligned
> ones. Given you're not worrying about alignment there anyway, why do
> the work? Also, we recommend unaligned output for script users so I
> don't feel right changing it.

I think this could be a separate feature.

> 3. How to show that a value is continued? As you can see below I use
> ':' before columns that have data. This obviously doesn't work for
> first column if there's no outer border. If your border style is 0
> you're totally out of luck.

I think you need to keep the normal delimiter and need some extra mark within 
the table cells.  (Think about how it would have to look in an HTML table.)

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


Re: Questions about proper newline handling in psql output

От
Martijn van Oosterhout
Дата:
On Tue, Sep 27, 2005 at 03:02:29PM +0200, Peter Eisentraut wrote:
> I don't think this is necessary.  If you put control characters into your
> text, then you clearly don't care about aligned output, so you don't get any.
> About \r, I think that needs to be figured into the alignment calculation, to
> work well on Windows and Mac.

Good point. On UNIX however, outputting a \r will jump back to the
beginning of the line, overwriting whatever was there. But you raise a
good question, should the output of psql be console specific. i.e. if
you insert a value with unix newlines then on a Mac the output won't
have linebreaks.

However, part of this discussion was because we were considering
changing the output of \df to display more info using multiple lines.
And if so we want it to display consistantly on all platforms, right?

My argument for the other control characters is: given the work to make
this work for \r, \t, and \n needs all this anyway, why not just fix it
for *all* control characters in one go and be completely solved of the
problem, for now and forever. If someone embeds the control characters
to change the title of your xterm, change the font, clear the screen,
etc should psql just blat that out? I realise it does it now and that
it's not a strong argument, but since we're here already...

> > 3. How to show that a value is continued? As you can see below I use
> > ':' before columns that have data. This obviously doesn't work for
> > first column if there's no outer border. If your border style is 0
> > you're totally out of luck.
>
> I think you need to keep the normal delimiter and need some extra mark within
> the table cells.  (Think about how it would have to look in an HTML table.)

Umm, I wasn't thinking of changing the HTML output at all, it doesn't
need it since whatever displays the HTML will take care of alignment.
Same for troff and CSV. Straight aligned text output is the only one we
care about AFAICS (and the only one that requires work to make it
happen).

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Re: Questions about proper newline handling in psql output

От
Martijn van Oosterhout
Дата:
On Tue, Sep 27, 2005 at 12:12:15AM -0000, Greg Sabino Mullane wrote:
> > 4. Some system output like pg_views has really really long strings,
> > would it be acceptable to change the output there to add newlines at
> > various places to make it output nicer with this change?
>
> I'd say no, until you propose a more concrete set of rules on how and when.

Well, I was thinking before the keywords SELECT, FROM, WHERE, AND,
ORDER BY, GROUP BY and HAVING. For bonus indent subqueries also. But
I'm not too fussed, it was just a thought. In fact, we already do it
for the output of \d for views, some maybe a hint from there...

> > Query is: select oid, prosrc as "HdrLine1 HdrLine2", proacl from pg_proc limit 1;
>
> Some smaller samples with a third column (and a large 2nd one) might be nice.

Ok, multiline strings in the pg_catalog are thin on the ground, I was
hoping to use real data rather than stuff I made up. (Real data has a
habit of showing weaknesses far better than things you dream up). But
I'll give it a shot.
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Re: Questions about proper newline handling in psql output

От
Bruce Momjian
Дата:
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---------------------------------------------------------------------------

Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> Hi,
> 
> I basically have a functional version for aligned output, examples at
> the bottom of this email. It handles multiline data values and
> multiline headers. However, there are some areas where I could use some
> input.
> 
> 1. To be able to control the spacing, psql now has to be very careful
> about its output. eg \r is printed as \r, ascii control characters are
> output as \x00 style and other control chars as \u0000. This is a
> change from previous behaviour, yet you're pretty much forced to if you
> want to control the output.
> 
> Is this change acceptable?
> 
> 2. Currently I've changed the aligned outputs but not the unaligned
> ones. Given you're not worrying about alignment there anyway, why do
> the work? Also, we recommend unaligned output for script users so I
> don't feel right changing it.
> 
> Is this distinction acceptable?
> 
> 3. How to show that a value is continued? As you can see below I use
> ':' before columns that have data. This obviously doesn't work for
> first column if there's no outer border. If your border style is 0
> you're totally out of luck.
> 
> I remember a discussion on this before but couldn't find it in the
> archives. Either a reference or some other hints would be appreciated.
> 
> 4. Some system output like pg_views has really really long strings,
> would it be acceptable to change the output there to add newlines at
> various places to make it output nicer with this change?
> 
> 5. Auto string folding. If a string is really long, fold it so it fits
> in a screen width, perhaps with '\' continuation. I havn't done this
> but I can imagine some people (including me) would love it.
> 
> 6. Currently I've implemented support for UTF-8 and all ASCII
> compatable single-byte encodings. Given that psql didn't support the
> others anyway maybe no-one cares, but I have to ask: does anyone care?
> If so, I need info on *how* to support an encoding.
> 
> Thanks for your attention. See you tomorrow.
> 
> Query is: select oid, prosrc as "HdrLine1
> HdrLine2", proacl from pg_proc limit 1;
> 
> Border style is 1.
>   oid  |                              HdrLine1                               | proacl 
>        |                              HdrLine2                               |        
> -------+---------------------------------------------------------------------+--------
>  17009 | select 1 union all select 2 union all select 3 union all            |       
>        :         select 4 union all select 5 union all select 6 union all            
>        :         select 7 union all select 8 union all select 9 union all            
>        :         select 10 union all select 11 union all select 12 union all         
>        :         select 13 union all select 14 union all select 15 union all         
>        :         select 16 union all select 17 union all select 18 union all         
>        :         select 19 union all select 20 union all select 21 union all         
>        :         select 22 union all select 23 union all select 24 union all         
>        :         select 25 union all select 26 union all select 27 union all         
>        :         select 28 union all select 29 union all select 30 union all         
>        :         select 31 union all select 32                                       
> (1 row)
> 
> Expanded display is on.
> -[ RECORD 1 ]-----------------------------------------------------------------
> oid      | 17009
> HdrLine1 | select 1 union all select 2 union all select 3 union all
> HdrLine2 :         select 4 union all select 5 union all select 6 union all
>          :         select 7 union all select 8 union all select 9 union all
>          :         select 10 union all select 11 union all select 12 union all
>          :         select 13 union all select 14 union all select 15 union all
>          :         select 16 union all select 17 union all select 18 union all
>          :         select 19 union all select 20 union all select 21 union all
>          :         select 22 union all select 23 union all select 24 union all
>          :         select 25 union all select 26 union all select 27 union all
>          :         select 28 union all select 29 union all select 30 union all
>          :         select 31 union all select 32
> proacl   | 
> 
> # select chr(8);
>  chr  
> ------
>  \x08
> (1 row)
> 
> 
> -- 
> Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> > tool for doing 5% of the work and then sitting around waiting for someone
> > else to do the other 95% so you can sue them.
-- End of PGP section, PGP failed!

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073