Here's the long-awaited next edition. For those who must get their hands
on some code I have a tarball at
http://www.pathwaynet.com/~peter/psql.tar.bz2
It includes a file RELEASENOTES which should help you get started.

CHANGELOG

* Sorted out -e and -E: -e toggles query echoing in non-interactive
  mode (why would you want to echo queries in interactive mode?). -E
  enables showing of queries sent behind your back and is independent
  of -e.
* Sorted out usernames and passwords: Switch -U specifies username or
  "?" for "prompt me". Switch -P is "prompt for password". Old -u is
  equivalent to -U ? -P. Equivalent changes to \connect (e.g., \c - ?
  = connect to current database and ask for new username (and prompting
  for password iff -u or -P mode)).
* Command history is saved and loaded automatically. Also, history and
  readline are separately enabled in the code. (like anyone needs that)
* Allow versioned startup files (like .psqlrc-6.6.0), at least during
  development.
* psql now has internal variables. Use \set and \unset to
  set/unset/display them. The amount of internal state got out of hand,
  so this should help. Most of the settings will be moved to some
  variable. (The implementation is currently quite naive, but
  encapsulated well to change it later on.)
* -q switch is now equivalent to setting variable quiet. Audited what
  messages should be quieted, what are errors, what is normal output,
  what is query output.
* Copy-in now has customizable prompt as well.
* Wrote a better strtok, with quoting capabilities, which is now used
  to parse the options of the slash commands. (This will break
  backward compatibility if you use filenames with spaces and quotes
  since they will now be interpreted differently. Too bad.)
* Cleaned up various \d<x> commands. The queries are now
  human-readable in -E mode. (Also they now show up in -E mode, and
  not in -e mode!)
* -E mode is now the variable echo_secret. If you set the variable to
  'noexec' then the "backdoor" queries will only be displayed, not
  executed. (Nice if you just want to study the queries.)
* If a connection goes bad during query execution, PQreset is
  attempted. If it still is bad, then an _interactive_ session will be
  in unconnected mode. (Changed prompt to reflect that.)
* Ctrl-C only sends cancel request if query in progress (otherwise
  default action = terminate program). This removes a major annoyance
  (I hope).
* Refined \c[onnect]'ion failures: Non-interactive scripts will
  terminate, even recursively. However, if the underlying session was
  an interactive one, it does not terminate. The database connection
  will be lost, however.
* Password prompts are automatic (both startup and \connect). Can
  still use -P switch, but that might prove unnecessary. [ Cheers to
  Roland R.! ]
* Implemented \lo_import, \lo_export, \lo_unlink, \lo_list. (Still
  needs some refinement, though.)
* Can now use \copy with oids and delimiters. No binary, yet.


TODO LIST

* generalized backslash command handling (struct, no ..else if...)
* new printing routines
* rewrite mainloop parser, strip comments
* single line mode doesn't take slash commands
* make scripts bomb out (optionally) on query error
* remove Rollback warnings in lo_ ops
* \default(s?) command
* allow several \ cmds on a line (add '\' to strtokx delims?, windows?)


SIDE NOTES

1. Since the new animal is now probably going to be 7.0, let's provide a
   psql that's worthy of that name, er, number. I hope I can lay a
   framework with this, but there are still a few months I think, so ideas
   are welcome.

1.a) On a related note, since the core developers have more important
   issues to worry about, I wouldn't mind maintaining/accompanying/taking
   care of/keeping an eye on/whatever psql until release (and possibly
   thereafter).
   
2. What about including an snprintf() into the source tree similar what is
   done with strdup()? (No, don't look at me, it totally escapes me how to
   do that and I don't want to cheat and look at the GNU sources for
   obvious reasons.)


-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Mon, 11 Oct 1999 21:43:16 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
psql Week 2
> * Ctrl-C only sends cancel request if query in progress (otherwise
>   default action = terminate program). This removes a major annoyance
>   (I hope).

Yes, I always wanted that fixed.  You have hit a number of other TODO
items.  Nice.

> * Refined \c[onnect]'ion failures: Non-interactive scripts will
>   terminate, even recursively. However, if the underlying session was
>   an interactive one, it does not terminate. The database connection
>   will be lost, however.

Nice.

> * Password prompts are automatic (both startup and \connect). Can
>   still use -P switch, but that might prove unnecessary. [ Cheers to
>   Roland R.! ]

Nice

> * Implemented \lo_import, \lo_export, \lo_unlink, \lo_list. (Still
>   needs some refinement, though.)

Also nice.
> * Can now use \copy with oids and delimiters. No binary, yet.

Yes, quite nice.

> 
> 
> TODO LIST
> 
> * generalized backslash command handling (struct, no ..else if...)
> * new printing routines

How about a backslash command to print the current date/time.  Good for
performance debugging.

> * rewrite mainloop parser, strip comments
> * single line mode doesn't take slash commands
> * make scripts bomb out (optionally) on query error
> * remove Rollback warnings in lo_ ops
> * \default(s?) command
> * allow several \ cmds on a line (add '\' to strtokx delims?, windows?)
> 
> 
> SIDE NOTES
> 
> 1. Since the new animal is now probably going to be 7.0, let's provide a
>    psql that's worthy of that name, er, number. I hope I can lay a
>    framework with this, but there are still a few months I think, so ideas
>    are welcome.
> 
> 1.a) On a related note, since the core developers have more important
>    issues to worry about, I wouldn't mind maintaining/accompanying/taking
>    care of/keeping an eye on/whatever psql until release (and possibly
>    thereafter).

Good.  It needs it.

>    
> 2. What about including an snprintf() into the source tree similar what is
>    done with strdup()? (No, don't look at me, it totally escapes me how to
>    do that and I don't want to cheat and look at the GNU sources for
>    obvious reasons.)

We can do that.  I thought we already did.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 11 Oct 1999 16:29:22 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] psql Week 2
Will the new psql replace the old one in 7.0? If so, I need to work on
it to incomporate the multi-byte capability. Peter, can you tell me
when you will finish the work?
---
Tatsuo Ishii


Tue, 12 Oct 1999 09:55:21 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] psql Week 2 
Peter Eisentraut <peter_e@gmx.net> writes:
> 2. What about including an snprintf() into the source tree similar what is
>    done with strdup()?

There is one in the backend/port/ directory, along with some other
important library routines that are missing on certain platforms.
Up to now we haven't worried about including these into anything but
the backend, but I see no reason not to include them into psql if
you need 'em.  (Probably would not be a good idea to put them into
libpq though, since that could cause conflicts with user apps that
supply their own versions.)  See backend/port/Makefile.in for the
tests that determine whether individual routines need to be included.

			regards, tom lane

Mon, 11 Oct 1999 21:28:15 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] psql Week 2 
On Oct 12, Tatsuo Ishii mentioned:

> Will the new psql replace the old one in 7.0? If so, I need to work on
> it to incomporate the multi-byte capability. Peter, can you tell me
> when you will finish the work?

If I don't terminally mess it up I thunk that was the plan.

I was initially planning on 4 weeks, but this week is really tight, so I
might need to finish with less. I don't want to occupy this thing forever
either.

Meanwhile I (think I) have been careful about multibyte stuff but it's
probably good if you take a look. Perhaps you can start with the tarball I
posted. It should be working.

	-Peter

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Wed, 13 Oct 1999 19:32:42 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: [HACKERS] psql Week 2 
On Oct 11, Tom Lane mentioned:

> Peter Eisentraut <peter_e@gmx.net> writes:
> > 2. What about including an snprintf() into the source tree similar what is
> >    done with strdup()?
> 
> There is one in the backend/port/ directory, along with some other
> important library routines that are missing on certain platforms.
> Up to now we haven't worried about including these into anything but
> the backend, but I see no reason not to include them into psql if
> you need 'em.  (Probably would not be a good idea to put them into
> libpq though, since that could cause conflicts with user apps that
> supply their own versions.)  See backend/port/Makefile.in for the
> tests that determine whether individual routines need to be included.

Okay, I'm sorry, I guess I never dug that far into the backend for that.
All those things seem kind of useful, so for good measure they could
perhaps be moved into the src/utils dir or a src/port dir.

I was not talking about putting them into libpq as public functions but if
someone working on libpq needed them there a way could surely be found.
Not me though right now.

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Wed, 13 Oct 1999 19:37:10 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: [HACKERS] psql Week 2 
> I was initially planning on 4 weeks, but this week is really tight, so I
> might need to finish with less. I don't want to occupy this thing forever
> either.

I'm not in hurry. I just want to make sure that I have enough time
before 7.0 is out. So keep your pace, please.

> Meanwhile I (think I) have been careful about multibyte stuff but it's
> probably good if you take a look. Perhaps you can start with the tarball I
> posted. It should be working.

That's a good news. I will check the tarbal.
---
Tatsuo Ishii

Thu, 14 Oct 1999 10:33:41 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] psql Week 2 