SEO

bruce wrote:
> Tom Lane wrote:
> > Bruce Momjian <bruce@momjian.us> writes:
> > > You are going to need to find community members who support your
> > > analysis if you want to make any headway in changing the patch.
> >
> > Let's turn that around, shall we? I think at this point it's *you*
> > that are standing alone and need to find someone who agrees with
> > your approach.
>
> I am confused exactly what people want changed in the patch. Some want
> no control over wrapping in file output, and others want $COLUMN to
> control column file output. The only person I am seeing code from is
> Greg Stark, but I think most don't want his changes.

Here is an email showing two people who want some way of getting wrapped
output into a file:

http://archives.postgresql.org/pgsql...4/msg00344.php

I think the API in the patch is the best I am going to do to keep
everyone happy --- 'wrapped' doesn't affect file/pipe output unless you
also tell it the width you want. Most interactive users are going to
set 'wrapped' and never set the width so it is automatically determined.

Some want wrapped to not affect file/pipe at all, while others (Greg
only?) want $COLUMNS to affect file/pipe output.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

"Bruce Momjian" <bruce@momjian.us> writes:

> I think the API in the patch is the best I am going to do to keep
> everyone happy --- 'wrapped' doesn't affect file/pipe output unless you
> also tell it the width you want. Most interactive users are going to
> set 'wrapped' and never set the width so it is automatically determined.

Aaah, I think that's the key to where we're going wrong.

Trying to use the columns logic to encode two separate decisions. "wrapped or
not wrapped" and "how wide".

I think this also clarifies Tom's objection. He's worried about people
configuring psql for interactive use and being surprised when their automated
scripts fail to parse the resulting output.

We do need a way to specifically request wrapped format, but if we want a way
to say "wrapped format only on a terminal" then we should have a mode for that
too.

But once we're in wrapped format we should stick to it and always follow the
same logic to determine the width.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Gregory Stark wrote:
> "Bruce Momjian" <bruce@momjian.us> writes:
>
> > I think the API in the patch is the best I am going to do to keep
> > everyone happy --- 'wrapped' doesn't affect file/pipe output unless you
> > also tell it the width you want. Most interactive users are going to
> > set 'wrapped' and never set the width so it is automatically determined.
>
> Aaah, I think that's the key to where we're going wrong.
>
> Trying to use the columns logic to encode two separate decisions. "wrapped or
> not wrapped" and "how wide".

Well, they kind of fit because there is no good way to know the width
they would want for file/pipe output (no the terminal width isn't very
helpful in most cases). Bottom line is we are going to need a way to
specify the width for wrapped file/pipe (COLUMNS is not something that
is easily set), and \pset columns seems to allow both the setting of the
width and saying we want wrapping for file/pipe.

I am not excited about 'wrapped-interactive' and 'wrapped-all' formats.
Do you have some other idea in mind?

> I think this also clarifies Tom's objection. He's worried about people
> configuring psql for interactive use and being surprised when their automated
> scripts fail to parse the resulting output.
>
> We do need a way to specifically request wrapped format, but if we want a way
> to say "wrapped format only on a terminal" then we should have a mode for that
> too.
>
> But once we're in wrapped format we should stick to it and always follow the
> same logic to determine the width.

I can't think of any cases where we have one setting for interactive and
another for all uses.

I do think we might be adding an 'auto' format the does
aligned/wrapped/expanded based on the table width, but only for
interactive use.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

"Bruce Momjian" <bruce@momjian.us> writes:

> I am not excited about 'wrapped-interactive' and 'wrapped-all' formats.
> Do you have some other idea in mind?

Some other idea for the name of it? Not particularly. I like your later
suggestion of "auto". Perhaps just "wrapped" and "auto"?

> I can't think of any cases where we have one setting for interactive and
> another for all uses.

In general I don't like such things but it seems to be what you're trying to
do. And also what Tom seems to be yearning for when he says that it shouldn't
affect file output. And if we do it we should do it properly and not hobble
both modes.

Note that basing it on the window size ioctl doesn't actually dtrt either.
What you really want is for it to depend on isatty(). If isatty(fout) is true
then you want to try to take the interactive default even if the ioctl fails.

Trying to join the two decisions means that nobody will be happy. If you ssh
in you won't get wrapped format, if you redirect to a file and specify wrapped
format explicitly you'll be frustrated that you're still not getting it. And
if you do want those things so you \pset columns you'll find it starts doing
it even when you -f file.dmp -- which doesn't seem bad to me but it means it
isn't satisfying your desires.

> I do think we might be adding an 'auto' format the does
> aligned/wrapped/expanded based on the table width, but only for
> interactive use.


--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Gregory Stark wrote:
> "Bruce Momjian" <bruce@momjian.us> writes:
>
> > I am not excited about 'wrapped-interactive' and 'wrapped-all' formats.
> > Do you have some other idea in mind?
>
> Some other idea for the name of it? Not particularly. I like your later
> suggestion of "auto". Perhaps just "wrapped" and "auto"?

Well, I was going to bring up changes to the default after the patch was
applied but I will bring it up now. I think there is some real
attractivness to having long values wrap to fit on your screen in
interactive mode. In fact, it is hard to justify our current
interactive behavior of a row just overflowing the screen width and
moving to the next line. We have gotten used to it, but it is certainly
not very user-friendly.

We have discussed having a formatting mode where aligned output switches
to expanded output when the row is too wide. One idea would be to
create an 'auto' mode that would display in aligned, or wrapped if that
doesn't fit, or expanded if that doesn't fit.

However, this idea really doesn't help us with the file/pipe idea. One
crazy idea would be for formatting to take two values, like:

\pset formatting wrapped aligned

where the first is for interactive use and the second is for file/pipe
output. Now, if they only specify one value, what does that control?

> > I can't think of any cases where we have one setting for interactive and
> > another for all uses.
>
> In general I don't like such things but it seems to be what you're trying to
> do. And also what Tom seems to be yearning for when he says that it shouldn't
> affect file output. And if we do it we should do it properly and not hobble
> both modes.
>
> Note that basing it on the window size ioctl doesn't actually dtrt either.
> What you really want is for it to depend on isatty(). If isatty(fout) is true
> then you want to try to take the interactive default even if the ioctl fails.

Yes, we do that now with $COLUMNS.

> Trying to join the two decisions means that nobody will be happy. If you ssh
> in you won't get wrapped format, if you redirect to a file and specify wrapped
> format explicitly you'll be frustrated that you're still not getting it. And
> if you do want those things so you \pset columns you'll find it starts doing
> it even when you -f file.dmp -- which doesn't seem bad to me but it means it
> isn't satisfying your desires.

I think we need to honor $COLUMNS if ioctl() fails.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Bruce Momjian wrote:
> > Trying to join the two decisions means that nobody will be happy. If you ssh
> > in you won't get wrapped format, if you redirect to a file and specify wrapped
> > format explicitly you'll be frustrated that you're still not getting it. And
> > if you do want those things so you \pset columns you'll find it starts doing
> > it even when you -f file.dmp -- which doesn't seem bad to me but it means it
> > isn't satisfying your desires.
>
> I think we need to honor $COLUMNS if ioctl() fails.

Clarification, honor $COLUMNS if ioctl() fails but only for interactive
mode.

If we can't make everyone happy we could just not add the patch. It
sounds crazy but we have had cases in the past where we couldn't get
concensus and we did nothing. Of course nothing is usually worse than
either option but groups behave in strange ways sometimes.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Bruce Momjian wrote:

> interactive mode. In fact, it is hard to justify our current
> interactive behavior of a row just overflowing the screen width and
> moving to the next line. We have gotten used to it, but it is certainly
> not very user-friendly.

+1

>
> We have discussed having a formatting mode where aligned output switches
> to expanded output when the row is too wide. One idea would be to
> create an 'auto' mode that would display in aligned, or wrapped if that
> doesn't fit, or expanded if that doesn't fit.
>
> However, this idea really doesn't help us with the file/pipe idea. One
> crazy idea would be for formatting to take two values, like:
>
> \pset formatting wrapped aligned

IMO we should never wrap file or pipe output. Once it leaves psql, it
should be up to whatever you pushed it through (file/pipe/script) to
handle formatting.

Sincerely,

Joshua D. Drake



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > We have discussed having a formatting mode where aligned output switches
> > to expanded output when the row is too wide. One idea would be to
> > create an 'auto' mode that would display in aligned, or wrapped if that
> > doesn't fit, or expanded if that doesn't fit.
> >
> > However, this idea really doesn't help us with the file/pipe idea. One
> > crazy idea would be for formatting to take two values, like:
> >
> > \pset formatting wrapped aligned
>
> IMO we should never wrap file or pipe output. Once it leaves psql, it
> should be up to whatever you pushed it through (file/pipe/script) to
> handle formatting.

Yes, I understand that argument, but the way we wrap values is something
an external tool is going to have great trouble duplicating.

For example, if I want to send wide psql output in email, right now I
just send it wide or use \x. With 'wrapped' I can set it to 72 columns
and get something I can email to people. I could copy it from my
screen, but if the output is more than a screen full it is much harder
to capture. (Yea, I could use 'script', but that isn't for the novice,
and I have no idea how that would be done on Win32.)

We could go with wrap only handling interactive and then see what
feedback we get from the field. For short output people can cut/paste
into files if they want wrapped output. That would eliminate the need
for \pset columns. We could just do ioctl() and check $COLUMNS.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Bruce Momjian wrote:

> For example, if I want to send wide psql output in email, right now I
> just send it wide or use \x. With 'wrapped' I can set it to 72 columns
> and get something I can email to people. I could copy it from my
> screen, but if the output is more than a screen full it is much harder
> to capture. (Yea, I could use 'script', but that isn't for the novice,
> and I have no idea how that would be done on Win32.)

I think your idea of novice is a little different than mine. A novice
isn't going to use this feature anyway, and by the time they start to
consider it (if they ever do), they will have already wrapped it in Perl
or C#.


Sincerely,

Joshua D. Drake

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* Bruce Momjian <bruce@momjian.us> [080424 23:14]:

> Well, I was going to bring up changes to the default after the patch was
> applied but I will bring it up now. I think there is some real
> attractivness to having long values wrap to fit on your screen in
> interactive mode. In fact, it is hard to justify our current
> interactive behavior of a row just overflowing the screen width and
> moving to the next line. We have gotten used to it, but it is certainly
> not very user-friendly.

-1.

Personally, I don't ever want to see that wrapped format.

<opinion valid="maybe not">
That wrapped format is more user-unfriendly than the long lines, which
are at least easily understandable.
</opinion>

So add a wrapped format, because obviously some people want it, but in a
similar vien to the making psql have no banner by default, I think
making wrapped format the default will cause much user consternation.

In Bruce's sample, even with the rules "right there", I still had to
look at the query to try and figure out what each data piece actually
was.

But I have to admit, trying to get a generic multi-column "wrapped"
format is a hard task. I couldn't come up with a scheme for showing it
easily myself on my (discarded) attempt to reply to the sample output.
Anything that *doesn't* have a wrapped line end with \ and then continue
with a > is going to feel awkward to me, and I'ld rather just have the
long lines, because having a one-off, complicated display format in
psql, even though it could technically define exactly what the data is
it's trying to display, if it's different from everything else means I'm
going to avoid it as much as possible.

a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFIEdbyuVxNPsxNPScRAoBPAKCW8EvHIaQ3JWmbUppFu0 BiTArimQCgglxq
66Ay4GDqySJiYavAEV89GfY=
=avI6
-----END PGP SIGNATURE-----