Re: Patch to change psql default banner v6

Hello,

As discussed:

http://archives.postgresql.org/pgsql-hackers/2008-04/msg01476.php

The patch does the following:

Adds an Execution line to the \? output.
Changes the help output in mainloop.c to be more useful.
Greatly reduces overall default banner output:
* shows client version and type help for help only
* if server doesn't match shows server version too
* if there is a major version mismatch it throws a warning

Sincerely,

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

On Wed, 23 Apr 2008 14:41:20 -0700
"Joshua D. Drake" <jd(at)commandprompt(dot)com> wrote:

Hello,

Per final discussion here:

http://archives.postgresql.org/pgsql-hackers/2008-04/msg01607.php

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Joshua D. Drake wrote:
> On Wed, 23 Apr 2008 14:41:20 -0700
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> wrote:
>
> Hello,
>
> Per final discussion here:
>
> http://archives.postgresql.org/pgsql-hackers/2008-04/msg01607.php

Isn't this going to mean \g is listed twice?

+ fprintf(output, _("Execution\n"));
+ fprintf(output, _(" \\g or ; execute query\n\n"));

If you want I can look at reorganizing the \? help. I have a larger
reorganization mind.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Joshua D. Drake wrote:
> On Wed, 23 Apr 2008 14:41:20 -0700
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> wrote:
>
> Hello,
>
> Per final discussion here:
>
> http://archives.postgresql.org/pgsql-hackers/2008-04/msg01607.php

I have looked over this patch and made a few adjustments.

You used for a help startup banner:

Type: help for help.

I feel this has too much indirection because 'help' then produced:

You are using psql, the command-line interface to PostgreSQL.

\h or \\help for SQL help.
\? for psql help.
\q to quit psql.

\copyright to view the copyright.

Because \? now has \h, \q, and \copyright alone at the top I think we
should just use:

$ psql test
psql (8.4devel) Type \? for help.

test=>

If you type 'help' it just repeats the startup banner suggestion:

test=> help

You are using psql, the command-line interface to PostgreSQL.
Type \? for help.

test=>

I think that consistency will be clearer. In the past we were trying to
avoid \?, but I think now it is clean enough to be used by new people
without confusion.

I also put the version number in parentheses so it wouldn't be as
prominent.

Updated patch attached.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

> I think that consistency will be clearer. In the past we were trying to
> avoid \?, but I think now it is clean enough to be used by new people
> without confusion.
>
> I also put the version number in parentheses so it wouldn't be as
> prominent.
>
> Updated patch attached.

FYI, after the patch is applied I will update psql banner examples in
our documentation.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian wrote:

> If you type 'help' it just repeats the startup banner suggestion:
>
> test=> help
>
> You are using psql, the command-line interface to PostgreSQL.
> Type \? for help.

I think we wanted to have more information in 'help', not less. Making
it just repeat the startup info is not very helpful.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > If you type 'help' it just repeats the startup banner suggestion:
> >
> > test=> help
> >
> > You are using psql, the command-line interface to PostgreSQL.
> > Type \? for help.
>
> I think we wanted to have more information in 'help', not less. Making
> it just repeat the startup info is not very helpful.

I thought about that, but aren't we just repeating the top of \?. Is
that helpful? Should we just display \?.

I know we decided not to do that, but I am trying to figure out what the
goal if 'help' is? To display the most frequently-used help commands?
Aren't they at the top of \?.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian wrote:
> Alvaro Herrera wrote:
>> Bruce Momjian wrote:
>>
>>> If you type 'help' it just repeats the startup banner suggestion:
>>>
>>> test=> help
>>>
>>> You are using psql, the command-line interface to PostgreSQL.
>>> Type \? for help.
>> I think we wanted to have more information in 'help', not less. Making
>> it just repeat the startup info is not very helpful.
>
> I thought about that, but aren't we just repeating the top of \?. Is
> that helpful? Should we just display \?.

I am a little confused here. The whole point of this patch is to remove
all extraneous information from the startup banner and push it to a
"help" screen. Thus type help for help.

If you type help you get your help options.

>
> I know we decided not to do that, but I am trying to figure out what the
> goal if 'help' is? To display the most frequently-used help commands?
> Aren't they at the top of \?.
>

The purpose of help is to provide what help options there are available
to those who need them.

Joshua D. Drake

Bruce Momjian wrote:

> I know we decided not to do that, but I am trying to figure out what the
> goal if 'help' is? To display the most frequently-used help commands?
> Aren't they at the top of \?.

The purpose of 'help' is to provide useful help. If it only says "see \?"
then it's just redirecting you somewhere else, which isn't useful.

I don't think the various help commands need to be completely
orthogonal. If you agree with that, then making 'help' repeat part of
what \? says is acceptable. (Of course, the idea is not just to repeat,
but also to provide useful advice to the unwary.)

Remember, the people who is going to type 'help' is not the 10-year-Pg-
experience types. It's the newbies.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > I know we decided not to do that, but I am trying to figure out what the
> > goal if 'help' is? To display the most frequently-used help commands?
> > Aren't they at the top of \?.
>
> The purpose of 'help' is to provide useful help. If it only says "see \?"
> then it's just redirecting you somewhere else, which isn't useful.
>
> I don't think the various help commands need to be completely
> orthogonal. If you agree with that, then making 'help' repeat part of
> what \? says is acceptable. (Of course, the idea is not just to repeat,
> but also to provide useful advice to the unwary.)

OK.

> Remember, the people who is going to type 'help' is not the 10-year-Pg-
> experience types. It's the newbies.

The larger issue is whether we want to advertise only "help" in the
startup banner. The patch has just:

Type: help for help.

Now, aside from being confusing (we need quotes around "help"), I
thought we should only mention \?.

My question is whether we agreed that suggesting "help" as the best way
to get help was what we agreed upon? If we did, I forgot. I thought
the 'help' ideas was just for people who forgot the help commands.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian wrote:

> My question is whether we agreed that suggesting "help" as the best way
> to get help was what we agreed upon? If we did, I forgot. I thought
> the 'help' ideas was just for people who forgot the help commands.

Please review the previous discussion:

http://archives.postgresql.org/message-id/1200851790.19135.68.camel%40greg-laptop

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > My question is whether we agreed that suggesting "help" as the best way
> > to get help was what we agreed upon? If we did, I forgot. I thought
> > the 'help' ideas was just for people who forgot the help commands.
>
> Please review the previous discussion:
>
> http://archives.postgresql.org/message-id/1200851790.19135.68.camel%40greg-laptop

OK, I just read the thread and saw no one say we should be promoting
_only_ 'help' in the startup banner. Where is that email discussion?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian wrote:
> Alvaro Herrera wrote:
>> Bruce Momjian wrote:
>>
>>> My question is whether we agreed that suggesting "help" as the best way
>>> to get help was what we agreed upon? If we did, I forgot. I thought
>>> the 'help' ideas was just for people who forgot the help commands.
>> Please review the previous discussion:
>>
>> http://archives.postgresql.org/message-id/1200851790.19135.68.camel%40greg-laptop
>
> OK, I just read the thread and saw no one say we should be promoting
> _only_ 'help' in the startup banner. Where is that email discussion?
>

http://archives.postgresql.org/pgsql-hackers/2008-04/msg01476.php

And most specifically:

http://archives.postgresql.org/pgsql-hackers/2008-04/msg01376.php

Joshua D. Drake

Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> >> Bruce Momjian wrote:
> >>
> >>> My question is whether we agreed that suggesting "help" as the best way
> >>> to get help was what we agreed upon? If we did, I forgot. I thought
> >>> the 'help' ideas was just for people who forgot the help commands.
> >> Please review the previous discussion:
> >>
> >> http://archives.postgresql.org/message-id/1200851790.19135.68.camel%40greg-laptop
> >
> > OK, I just read the thread and saw no one say we should be promoting
> > _only_ 'help' in the startup banner. Where is that email discussion?
> >
>
> http://archives.postgresql.org/pgsql-hackers/2008-04/msg01476.php
>
> And most specifically:
>
> http://archives.postgresql.org/pgsql-hackers/2008-04/msg01376.php

Ah, OK. I had forgotten. Here is the new output:

$ sql test
psql (8.4devel) Type "help" for help.

test=> help

You are using psql, the command-line interface to PostgreSQL.
\h or \help for SQL help
\? for psql help
\q to quit psql

\copyright to view the copyright

test=> \?
General
\copyright show PostgreSQL usage and distribution terms
\g [FILE] or ; send query buffer to server (and results to file or |pipe)
\h [NAME] help on syntax of SQL commands, * for all commands
\q quit psql

Query Buffer
\e [FILE] edit the query buffer (or file) with external editor
...

I moved '\g' up into the "General" section rather than make it a
single-entry section.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian wrote:

>
> test=> \?
> General
> \copyright show PostgreSQL usage and distribution terms
> \g [FILE] or ; send query buffer to server (and results to file or |pipe)
> \h [NAME] help on syntax of SQL commands, * for all commands
> \q quit psql
>
> Query Buffer
> \e [FILE] edit the query buffer (or file) with external editor
> ...
>
> I moved '\g' up into the "General" section rather than make it a
> single-entry section.

"send query buffer to server means nothing to a newbie". You execute
queries, you don't send buffers (from a user perspective).

Sincerely,

Joshua D. Drake

Joshua D. Drake wrote:
> Bruce Momjian wrote:
>
> >
> > test=> \?
> > General
> > \copyright show PostgreSQL usage and distribution terms
> > \g [FILE] or ; send query buffer to server (and results to file or |pipe)
> > \h [NAME] help on syntax of SQL commands, * for all commands
> > \q quit psql
> >
> > Query Buffer
> > \e [FILE] edit the query buffer (or file) with external editor
> > ...
> >
> > I moved '\g' up into the "General" section rather than make it a
> > single-entry section.
>
> "send query buffer to server means nothing to a newbie". You execute
> queries, you don't send buffers (from a user perspective).

Yep, good, updated:

General
\copyright show PostgreSQL usage and distribution terms
\g [FILE] or ; execute query (and send results to file or |pipe)
\h [NAME] help on syntax of SQL commands, * for all commands
\q quit psql

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian wrote:
> Joshua D. Drake wrote:
>> Bruce Momjian wrote:

>>> I moved '\g' up into the "General" section rather than make it a
>>> single-entry section.
>> "send query buffer to server means nothing to a newbie". You execute
>> queries, you don't send buffers (from a user perspective).
>
> Yep, good, updated:
>
> General
> \copyright show PostgreSQL usage and distribution terms
> \g [FILE] or ; execute query (and send results to file or |pipe)
> \h [NAME] help on syntax of SQL commands, * for all commands
> \q quit psql
>
>

Cool.

Joshua D. Drake

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Ah, OK. I had forgotten. Here is the new output:

> $ sql test
> psql (8.4devel) Type "help" for help.

> test=> help

You are being unreasonably cryptic here. What happens when there
is optional output --- ie, version mismatch warning and/or SSL info?

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Ah, OK. I had forgotten. Here is the new output:
>
> > $ sql test
> > psql (8.4devel) Type "help" for help.
>
> > test=> help
>
> You are being unreasonably cryptic here. What happens when there
> is optional output --- ie, version mismatch warning and/or SSL info?

Oh, good point. Let me look at that. Thanks. You prefer:

$ sql test
psql (8.4devel)
Type "help" for help.

test=> help

That looked so sparse to me.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Oh, good point. Let me look at that. Thanks. You prefer:

> $ sql test
> psql (8.4devel)
> Type "help" for help.

> test=> help

Well, the question is still "where is the optional info going to go?"

I think what I'd find nice looking is

$ psql test
psql 8.4devel [ server version warning here, if needed ]
[ line with SSL info here, if needed ]
Type "help" for help.

test=>

I do feel that the help statement ought to be on its own line;
the other way is going to look cluttered, particularly as soon
as there's a version warning in there.

regards, tom lane

Tom Lane wrote:

> Well, the question is still "where is the optional info going to go?"
>
> I think what I'd find nice looking is
>
> $ psql test
> psql 8.4devel [ server version warning here, if needed ]
> [ line with SSL info here, if needed ]
> Type "help" for help.
>
> test=>
>
> I do feel that the help statement ought to be on its own line;
> the other way is going to look cluttered, particularly as soon
> as there's a version warning in there.

O.k. I am not trying to start an argument here but... I already sent 6
revisions of this patch that received comments and had thorough review
via Alvaro. I even took into account Tom's original comments from the
previous thread.

This much effort on something so simple makes it not worth the effort in
the first place.

Bruce with respect the only useful thing I have seen you do to the patch
in all this wrangling is realign the \? General options and frankly even
that is suspect in my opinion. Can we either throw it away and say,
"Nice try JD" or just commit the thing.

Joshua D. Drake

>
> regards, tom lane
>

Joshua D. Drake wrote:
> O.k. I am not trying to start an argument here but... I already sent 6
> revisions of this patch that received comments and had thorough review
> via Alvaro. I even took into account Tom's original comments from the
> previous thread.
>
> This much effort on something so simple makes it not worth the effort in
> the first place.
>
> Bruce with respect the only useful thing I have seen you do to the patch
> in all this wrangling is realign the \? General options and frankly even
> that is suspect in my opinion. Can we either throw it away and say,
> "Nice try JD" or just commit the thing.

Your patch is getting the same review any other patch would have. If
you want someone else to apply it I will stop working on it.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Joshua D. Drake wrote:
>
> O.k. I am not trying to start an argument here but... I already sent 6
> revisions of this patch that received comments and had thorough review
> via Alvaro. I even took into account Tom's original comments from the
> previous thread.
>
> This much effort on something so simple makes it not worth the effort
> in the first place.
>
>

Welcome to UI development. There is always *far* more argument of minor
matters of appearance than over anything else, in my experience.

cheers

andrew

On Thu, 15 May 2008 11:46:41 -0400 (EDT)
Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> > Bruce with respect the only useful thing I have seen you do to the
> > patch in all this wrangling is realign the \? General options and
> > frankly even that is suspect in my opinion. Can we either throw it
> > away and say, "Nice try JD" or just commit the thing.
>
> Your patch is getting the same review any other patch would have. If
> you want someone else to apply it I will stop working on it.

I am not asking you to not review the patch. I am asking you to be
productive in doing so. Your review of this patch is basically, "Even
though there were two very long threads with several (on the greater
side of several) different people contributing feedback, I think I know
better".

That behavior is frustrating, especially when I took an extreme amount
of effort to address all concerns ahead of the actual commit fest. I
wanted to make sure the patch would be easy to review and easy to
commit. If I thought I was going to have to have the argument all over
again, I just would have left the first submission as it was and then
we could have burned all the time during commit fest only.

Now Alvaro, Tom and I are all having the same discussion all over again
but this time with Bruce. It makes no sense.

Sincerely,

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Andrew Dunstan wrote:

> Welcome to UI development. There is always *far* more argument of minor
> matters of appearance than over anything else, in my experience.

Which is a good thing (in this case at least), because otherwise we
would end up with a crappy UI just because a single person thinks it's
"good enough".

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Oh, good point. Let me look at that. Thanks. You prefer:
>
> > $ sql test
> > psql (8.4devel)
> > Type "help" for help.
>
> > test=> help
>
> Well, the question is still "where is the optional info going to go?"
>
> I think what I'd find nice looking is
>
> $ psql test
> psql 8.4devel [ server version warning here, if needed ]
> [ line with SSL info here, if needed ]
> Type "help" for help.
>
> test=>
>
> I do feel that the help statement ought to be on its own line;
> the other way is going to look cluttered, particularly as soon
> as there's a version warning in there.

OK, here is the normal startup now:

$ sql test
psql (8.4.0)
Type "help" for help.

test=>

Here is a minor version mismatch:

$ sql test
psql (8.4.0, server 8.4.1)
Type "help" for help.

test=>

Here is a major version mismatch:

$ sql test
psql (8.4.0, server 8.3.1)
WARNING: psql version 8.4.0, server version 8.3.1.
Some psql features might not work.
Type "help" for help.

test=>

I have also added '\g' to the 'help' display:

test=> help

You are using psql, the command-line interface to PostgreSQL.
\? for psql help
\h or \help for SQL help

\g or ";" to execute a query
\q to quit psql

\copyright to view the copyright

test=>

I don't know how to generate an SSL message.

With the new smaller \? "General" section, I though it was worth
considering if we still want to do the help banner the same. Obviously
we do, but I wanted to explore it.

Patch attached.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>
>> Welcome to UI development. There is always *far* more argument of minor
>> matters of appearance than over anything else, in my experience.
>
> Which is a good thing (in this case at least), because otherwise we
> would end up with a crappy UI just because a single person thinks it's
> "good enough".

This makes me think we shouldn't be hard-coding anything at all
as the welcome message; but rather having a default .psqlrc
in much the same way that that there's a default /etc/bash.bashrc
and /etc/csh.login.

Within that default .psqlrc we can put
\qecho "Whatever the default message is"
or
select "my message "+version();
to create the default, but then anyone with their own .psqlrc
can re-define it to whatever they think is a "good enough" UI.

Ron Mayer wrote:
> Alvaro Herrera wrote:
> > Andrew Dunstan wrote:
> >
> >> Welcome to UI development. There is always *far* more argument of minor
> >> matters of appearance than over anything else, in my experience.
> >
> > Which is a good thing (in this case at least), because otherwise we
> > would end up with a crappy UI just because a single person thinks it's
> > "good enough".
>
>
> This makes me think we shouldn't be hard-coding anything at all
> as the welcome message; but rather having a default .psqlrc
> in much the same way that that there's a default /etc/bash.bashrc
> and /etc/csh.login.
>
> Within that default .psqlrc we can put
> \qecho "Whatever the default message is"
> or
> select "my message "+version();
> to create the default, but then anyone with their own .psqlrc
> can re-define it to whatever they think is a "good enough" UI.

We could do that but we still have to design the default banner.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Ron Mayer wrote:
>> This makes me think we shouldn't be hard-coding anything at all
>> as the welcome message; but rather having a default .psqlrc
>> in much the same way that that there's a default /etc/bash.bashrc
>> and /etc/csh.login.
>>
>> Within that default .psqlrc we can put
>> \qecho "Whatever the default message is"
>> or
>> select "my message "+version();
>> to create the default, but then anyone with their own .psqlrc
>> can re-define it to whatever they think is a "good enough" UI.

> We could do that but we still have to design the default banner.

More to the point, we would then have to design API with which a
custom .psqlrc could put out information about psql version,
server version, SSL status, etc. It would take a lot of work
to make this approach actually useful, and there isn't demand
to justify it AFAIK.

It's worth polishing the default behavior in any case, because
that is what newbies are going to see.

regards, tom lane

I'm OK with thisG but please move the printSSLInfo() call just before
echoing the help line.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera wrote:
>
> I'm OK with thisG but please move the printSSLInfo() call just before
> echoing the help line.

Oh, good catch, moved. I also moved the Win32 code page message up too.
Patch attached.

I hacked up an example that shows both SSL and Win32 code page messages:

$ psql test
psql (8.4devel)
SSL connection (cipher: 2343, bits: 512)
WARNING: Console code page (323) differs from Windows code page (2323)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
Type "help" for help.

test=>

With major version mismatches it looks like this:

$ psql test
psql (8.4devel)
SSL connection (cipher: 2343, bits: 512)
WARNING: Console code page (323) differs from Windows code page (2323)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
WARNING: psql version 8.4.0, server version 8.3.1.
Some psql features might not work.
Type "help" for help.

test=>

By indenting those messages the 'help' message still stands out.
Adjustments?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> With major version mismatches it looks like this:

> $ psql test
> psql (8.4devel)
> SSL connection (cipher: 2343, bits: 512)
> WARNING: Console code page (323) differs from Windows code page (2323)
> 8-bit characters might not work correctly. See psql reference
> page "Notes for Windows users" for details.
> WARNING: psql version 8.4.0, server version 8.3.1.
> Some psql features might not work.
> Type "help" for help.

> By indenting those messages the 'help' message still stands out.

My advice: don't do that, it just looks weird. Both of these look
fine to me:

$ psql test
psql (8.4devel)
SSL connection (cipher: 2343, bits: 512)
Type "help" for help.

$ psql test
psql (8.4devel)
SSL connection (cipher: 2343, bits: 512)
WARNING: Console code page (323) differs from Windows code page (2323)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
WARNING: psql version 8.4.0, server version 8.3.1.
Some psql features might not work.
Type "help" for help.

Also, maybe it's just me, but I think you have put the order of these
optional things exactly backwards. I'd do

$ psql test
psql (8.4devel)
WARNING: psql version 8.4.0, server version 8.3.1.
Some psql features might not work.
WARNING: Console code page (323) differs from Windows code page (2323)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
SSL connection (cipher: 2343, bits: 512)
Type "help" for help.

Why? Well, it's just more nearly the way it used to be.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > With major version mismatches it looks like this:
>
> > $ psql test
> > psql (8.4devel)
> > SSL connection (cipher: 2343, bits: 512)
> > WARNING: Console code page (323) differs from Windows code page (2323)
> > 8-bit characters might not work correctly. See psql reference
> > page "Notes for Windows users" for details.
> > WARNING: psql version 8.4.0, server version 8.3.1.
> > Some psql features might not work.
> > Type "help" for help.
>
> > By indenting those messages the 'help' message still stands out.
>
> My advice: don't do that, it just looks weird. Both of these look
> fine to me:
>
> $ psql test
> psql (8.4devel)
> SSL connection (cipher: 2343, bits: 512)
> Type "help" for help.
>
> $ psql test
> psql (8.4devel)
> SSL connection (cipher: 2343, bits: 512)
> WARNING: Console code page (323) differs from Windows code page (2323)
> 8-bit characters might not work correctly. See psql reference
> page "Notes for Windows users" for details.
> WARNING: psql version 8.4.0, server version 8.3.1.
> Some psql features might not work.
> Type "help" for help.
>
> Also, maybe it's just me, but I think you have put the order of these
> optional things exactly backwards. I'd do
>
> $ psql test
> psql (8.4devel)
> WARNING: psql version 8.4.0, server version 8.3.1.
> Some psql features might not work.
> WARNING: Console code page (323) differs from Windows code page (2323)
> 8-bit characters might not work correctly. See psql reference
> page "Notes for Windows users" for details.
> SSL connection (cipher: 2343, bits: 512)
> Type "help" for help.
>
> Why? Well, it's just more nearly the way it used to be.

OK, here is the mega-print:

$ psql test
psql (8.4devel, server 8.4devel)
WARNING: psql version 8.4, server version 8.4.
Some psql features might not work.
WARNING: Console code page (44) differs from Windows code page (55)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
SSL connection (cipher: 55, bits: 512)
Type "help" for help.

test=>

Patch at ftp://momjian.us/pub/postgresql/mypatches/help.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

On Thu, May 15, 2008 at 10:20:53AM -0700, Ron Mayer wrote:
> Alvaro Herrera wrote:
> >Andrew Dunstan wrote:
> >
> >>Welcome to UI development. There is always *far* more argument of minor
> >>matters of appearance than over anything else, in my experience.
> >
> >Which is a good thing (in this case at least), because otherwise we
> >would end up with a crappy UI just because a single person thinks it's
> >"good enough".
>
>
> This makes me think we shouldn't be hard-coding anything at all
> as the welcome message; but rather having a default .psqlrc
> in much the same way that that there's a default /etc/bash.bashrc
> and /etc/csh.login.
>
> Within that default .psqlrc we can put
> \qecho "Whatever the default message is"
> or
> select "my message "+version();
> to create the default, but then anyone with their own .psqlrc
> can re-define it to whatever they think is a "good enough" UI.

+1
Including no banner at all please.

--
David Gould daveg(at)sonic(dot)net 510 536 1443 510 282 0869
If simplicity worked, the world would be overrun with insects.

daveg wrote:
> On Thu, May 15, 2008 at 10:20:53AM -0700, Ron Mayer wrote:
> > Alvaro Herrera wrote:
> > >Andrew Dunstan wrote:
> > >
> > >>Welcome to UI development. There is always *far* more argument of minor
> > >>matters of appearance than over anything else, in my experience.
> > >
> > >Which is a good thing (in this case at least), because otherwise we
> > >would end up with a crappy UI just because a single person thinks it's
> > >"good enough".
> >
> >
> > This makes me think we shouldn't be hard-coding anything at all
> > as the welcome message; but rather having a default .psqlrc
> > in much the same way that that there's a default /etc/bash.bashrc
> > and /etc/csh.login.
> >
> > Within that default .psqlrc we can put
> > \qecho "Whatever the default message is"
> > or
> > select "my message "+version();
> > to create the default, but then anyone with their own .psqlrc
> > can re-define it to whatever they think is a "good enough" UI.
>
> +1
> Including no banner at all please.

There is a psql quiet option that shows no banner:

-q
--quiet
Specifies that psql should do its work quietly. By
default, it prints welcome messages and various
informational output. If this option is used, none
of this happens. This is useful with the -c option.
Within psql you can also set the QUIET variable to
achieve the same effect.

You could then use \echo in .psqlrc to make your own banner.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

On Thu, May 15, 2008 at 12:09:25PM -0400, Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>
> > Welcome to UI development. There is always *far* more argument of minor
> > matters of appearance than over anything else, in my experience.
>
> Which is a good thing (in this case at least), because otherwise we
> would end up with a crappy UI just because a single person thinks it's
> "good enough".

I hate to bike-shed this even further, but I'd like to make those
"incompatibility" messages just go away by making 8.4's psql (and all
those going forward) support every living version of Postgres at the
time of their release, so 8.4's psql would be able to talk seamlessly
to Postgres 7.4 :)

Cheers,
David (well, not really bike-shedding, but trying to propose a feature
that reduces the amount of UI clutter)
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

"Alvaro Herrera" <alvherre(at)commandprompt(dot)com> writes:

> Bruce Momjian wrote:
>
>> I know we decided not to do that, but I am trying to figure out what the
>> goal if 'help' is? To display the most frequently-used help commands?
>> Aren't they at the top of \?.
>
> The purpose of 'help' is to provide useful help. If it only says "see \?"
> then it's just redirecting you somewhere else, which isn't useful.

Haven't been following this thread. Has the idea of making "help" just a
synonym for \? not come up? Or has it been rejected? It seems simplest.

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

David Fetter wrote:
>
> I hate to bike-shed this even further, but I'd like to make those
> "incompatibility" messages just go away by making 8.4's psql (and all
> those going forward) support every living version of Postgres at the
> time of their release, so 8.4's psql would be able to talk seamlessly
> to Postgres 7.4 :)
>
>

I think you must have been out in the sun too long.

Just look at the pg_dump code if you want something of an idea of what
this would involve.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> David Fetter wrote:
>> I hate to bike-shed this even further, but I'd like to make those
>> "incompatibility" messages just go away by making 8.4's psql (and all
>> those going forward) support every living version of Postgres at the
>> time of their release,

> I think you must have been out in the sun too long.

Hey, he's welcome to try to do it. But it's utterly unrelated to the
patch at hand, and we are not holding up the patch at hand until
something like that happens.

regards, tom lane

On Thu, May 15, 2008 at 06:55:31PM -0400, Andrew Dunstan wrote:
> David Fetter wrote:
>>
>> I hate to bike-shed this even further, but I'd like to make those
>> "incompatibility" messages just go away by making 8.4's psql (and
>> all those going forward) support every living version of Postgres
>> at the time of their release, so 8.4's psql would be able to talk
>> seamlessly to Postgres 7.4 :)
>
> I think you must have been out in the sun too long.

One thing I really treasure about working on the Postgres project is
frank feedback. :)

> Just look at the pg_dump code if you want something of an idea of
> what this would involve.

Given that each previous version tied backslash commands to some
particular chunk of SQL, what would be the problem with either
immediately or lazily setting those to the chunks of SQL already
present in previous versions?

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Thu, May 15, 2008 at 06:57:12PM -0400, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > David Fetter wrote:
> >> I hate to bike-shed this even further, but I'd like to make those
> >> "incompatibility" messages just go away by making 8.4's psql (and
> >> all those going forward) support every living version of Postgres
> >> at the time of their release,
>
> > I think you must have been out in the sun too long.
>
> Hey, he's welcome to try to do it. But it's utterly unrelated to
> the patch at hand, and we are not holding up the patch at hand until
> something like that happens.

Nor am I suggesting holding up this patch for that reason :)

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

David Fetter wrote:
> On Thu, May 15, 2008 at 06:55:31PM -0400, Andrew Dunstan wrote:
>
>> David Fetter wrote:
>>
>>> I hate to bike-shed this even further, but I'd like to make those
>>> "incompatibility" messages just go away by making 8.4's psql (and
>>> all those going forward) support every living version of Postgres
>>> at the time of their release, so 8.4's psql would be able to talk
>>> seamlessly to Postgres 7.4 :)
>>>
>> I think you must have been out in the sun too long.
>>
>
> One thing I really treasure about working on the Postgres project is
> frank feedback. :)
>

I know you know me well enough to realise there was an implied smiley ;-)

>
>> Just look at the pg_dump code if you want something of an idea of
>> what this would involve.
>>
>
> Given that each previous version tied backslash commands to some
> particular chunk of SQL, what would be the problem with either
> immediately or lazily setting those to the chunks of SQL already
> present in previous versions?
>
>
>

First, this is not a cost free exercise - it increases code complexity
enormously.

Second, it's not nearly as easy as that:
. new commands have been added
. postgres features have been added
. catalogs have changed

Among other things, help and indeed the available command set would have
to become server version sensitive.

And you would greatly increase the bar for anyone wanting to add a new
command - now they (or someone) would have to work out how the command
would or might work n versions back, not just with the current dev version.

Doing it lazily isn't acceptable - if we promise \command compatibility
with previous server versions then we need to deliver it to the maximum
extent possible, and if we don't promise it there's no point in doing this.

And, as Tom says, it has nothing really to do with this patch.

cheers

andrew

Andrew Dunstan wrote:

> Second, it's not nearly as easy as that:
> . new commands have been added
> . postgres features have been added
> . catalogs have changed

Well, this just means a different piece of SQL needs to be sent for a
command depending on the server version, right? It's not like that's
tremendously different. The nice thing about most \X commands is that
they embed everything they need in a bunch of SQL, and they don't need
much else in C code. So it's not all that difficult.

And for commands that have been added later, an initial version could
just say "this server version does not support this command". It would
be already a huge improvement.

Probably the biggest change would be to support versions that did not
have schemas, but I think it would be OK to punt on that. We already
stopped supporting 7.2 anyway.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>
>
>> Second, it's not nearly as easy as that:
>> . new commands have been added
>> . postgres features have been added
>> . catalogs have changed
>>
>
> Well, this just means a different piece of SQL needs to be sent for a
> command depending on the server version, right? It's not like that's
> tremendously different. The nice thing about most \X commands is that
> they embed everything they need in a bunch of SQL, and they don't need
> much else in C code. So it's not all that difficult.
>
> And for commands that have been added later, an initial version could
> just say "this server version does not support this command". It would
> be already a huge improvement.
>
> Probably the biggest change would be to support versions that did not
> have schemas, but I think it would be OK to punt on that. We already
> stopped supporting 7.2 anyway.
>

Have at it then. Prove me wrong.

cheers

andrew

Andrew Dunstan wrote:

>> And for commands that have been added later, an initial version could
>> just say "this server version does not support this command". It would
>> be already a huge improvement.
>>
>> Probably the biggest change would be to support versions that did not
>> have schemas, but I think it would be OK to punt on that. We already
>> stopped supporting 7.2 anyway.
>>
>
> Have at it then. Prove me wrong.

IMO the problem isn't the one off support for all supported version of
Pg... say 7.4 -> 8.4. The problem is of on going maintenance.

/me doesn't think it is worth the effort.

Sincerely,

Joshua D. Drake

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> Andrew Dunstan wrote:
>> Have at it then. Prove me wrong.

> IMO the problem isn't the one off support for all supported version of
> Pg... say 7.4 -> 8.4. The problem is of on going maintenance.

> /me doesn't think it is worth the effort.

Since no one's done it yet, that would seem to be the consensus
opinion :-)

Still, it'd be interesting to see an attempt at making it go.
The costs of doing it now for existing versions would probably give us
a good idea of what the future maintenance effort might be like.
Without a real patch to look at, we're all just guessing about that.

regards, tom lane

On Thu, May 15, 2008 at 03:21:37PM -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> >
> > I'm OK with thisG but please move the printSSLInfo() call just before
> > echoing the help line.
>
> Oh, good catch, moved. I also moved the Win32 code page message up too.
> Patch attached.
>
> I hacked up an example that shows both SSL and Win32 code page messages:

I believe there's a bug in this patch, namely that the warnings when
there's a server-client mismatch only appear at startup time. This is
a pretty clear POLA violation, IMHO.

On my laptop, I have two pg instances running: 8.3.0 on port 5432, CVS
TIP on 2225.

Here's what I get if I invoke psql from the command line:

$ psql -p 5432 postgres
Welcome to psql 8.4devel (server 8.3.0), the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit

WARNING: You are connected to a server with major version 8.3,
but your psql client is major version 8.4. Some backslash commands,
such as \d, might not work properly.

Here's what I get if I use \c, having connected to CVS TIP first:

davidfetter(at)postgres=# \c - - - 5432
You are now connected to database "postgres" at port "5432".

I think that the warning should be consistently there on connect
instead of just at program start.

Not coincidentally, moving all the checks into one spot, i.e. making
startup.c and command.c call and test the same things to connect to a
database, advances my Evil Plan™ to make more interesting things
happen when switching versions :)

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

David Fetter <david(at)fetter(dot)org> writes:
> I believe there's a bug in this patch, namely that the warnings when
> there's a server-client mismatch only appear at startup time.

Please do not blame this patch for a problem that has been there all
along.

I don't say that the point doesn't need investigation, but blaming
the patch-at-hand for the issue is just misleading.

regards, tom lane

On Fri, May 16, 2008 at 01:22:55AM -0400, Tom Lane wrote:
> David Fetter <david(at)fetter(dot)org> writes:
> > I believe there's a bug in this patch, namely that the warnings when
> > there's a server-client mismatch only appear at startup time.
>
> Please do not blame this patch for a problem that has been there all
> along.
>
> I don't say that the point doesn't need investigation, but blaming
> the patch-at-hand for the issue is just misleading.

The patch at hand, as you point out, emphasizes a problem that's been
there all along, namely that \c doesn't do the same things that
command line connection does.

I'm volunteering to make them use the same methods :)

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Bruce Momjian wrote:
> OK, here is the mega-print:
>
> $ psql test
> psql (8.4devel, server 8.4devel)
> WARNING: psql version 8.4, server version 8.4.
> Some psql features might not work.
> WARNING: Console code page (44) differs from Windows code page (55)
> 8-bit characters might not work correctly. See psql reference
> page "Notes for Windows users" for details.
> SSL connection (cipher: 55, bits: 512)
> Type "help" for help.
>
> test=>
>

Updated patch applied, docs adjusted for new psql startup banner.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Tom Lane a écrit :
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>> Andrew Dunstan wrote:
>>> Have at it then. Prove me wrong.
>
>> IMO the problem isn't the one off support for all supported version of
>> Pg... say 7.4 -> 8.4. The problem is of on going maintenance.
>
>> /me doesn't think it is worth the effort.
>
> Since no one's done it yet, that would seem to be the consensus
> opinion :-)
>
> Still, it'd be interesting to see an attempt at making it go.
> The costs of doing it now for existing versions would probably give us
> a good idea of what the future maintenance effort might be like.
> Without a real patch to look at, we're all just guessing about that.
>

Here is a patch that tries to implement this. Meta-commands should work
from 7.4 to 8.4-devel releases. It was not hard to do, and I don't think
it really is a burden to maintain.

One part left to fix is \du and \dg commands. I would be glad to
continue to work on this but I would prefer to have comments before.

Thanks.

Regards.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

Guillaume Lelarge wrote:
> Here is a patch that tries to implement this. Meta-commands should
> work from 7.4 to 8.4-devel releases. It was not hard to do, and I
> don't think it really is a burden to maintain.
>
> One part left to fix is \du and \dg commands. I would be glad to
> continue to work on this but I would prefer to have comments before.
Good work! I submitted a similar patch also.

For your patch I have one critique: the version sensitive code is
scattered all through describe.c. Are there opportunities to apply some
tests at a higher level (reducing the number of tests), or gather the
tests into an easily maintainable chunk?

The cleaner it is, the more likely future patchers will continue to
maintain compatibility.

-Bryce Nesbitt

Bryce Nesbitt a écrit :
> Guillaume Lelarge wrote:
>> Here is a patch that tries to implement this. Meta-commands should
>> work from 7.4 to 8.4-devel releases. It was not hard to do, and I
>> don't think it really is a burden to maintain.
>>
>> One part left to fix is \du and \dg commands. I would be glad to
>> continue to work on this but I would prefer to have comments before.
> Good work! I submitted a similar patch also.

Yes, I've seen that.

> For your patch I have one critique: the version sensitive code is
> scattered all through describe.c. Are there opportunities to apply some
> tests at a higher level (reducing the number of tests), or gather the
> tests into an easily maintainable chunk?
>

I can't find an easy way to do this. And question is: is it really
interesting to do this? I'm not sure it's worth it. If you want to work
on this and patch my patch, you're welcome :)

> The cleaner it is, the more likely future patchers will continue to
> maintain compatibility.
>

+1

Attached is a new version of the patch. It fixes a few issues when one
adds a pattern to metacommands.

Regards.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

David Fetter wrote:
> On Fri, May 16, 2008 at 01:22:55AM -0400, Tom Lane wrote:
> > David Fetter <david(at)fetter(dot)org> writes:
> > > I believe there's a bug in this patch, namely that the warnings when
> > > there's a server-client mismatch only appear at startup time.
> >
> > Please do not blame this patch for a problem that has been there all
> > along.
> >
> > I don't say that the point doesn't need investigation, but blaming
> > the patch-at-hand for the issue is just misleading.
>
> The patch at hand, as you point out, emphasizes a problem that's been
> there all along, namely that \c doesn't do the same things that
> command line connection does.
>
> I'm volunteering to make them use the same methods :)

David, I have fixed this problem with the attached, applied patch.
Thanks for the observation. (The patch also removes a duplicate
definition of parse_version().)

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Guillaume Lelarge <guillaume(at)lelarge(dot)info> writes:
> Attached is a new version of the patch. It fixes a few issues when one
> adds a pattern to metacommands.

Applied with some editorialization. There were some places you
evidently hadn't tested against all supported server versions ...

regards, tom lane