Обсуждение: psql Week 2
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 interactivemode?). -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 andask 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. (likeanyone 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 ofhand, so this should help. Most of the settings will be moved to some variable. (The implementation is currently quitenaive, 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 isnormal 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 willbreak 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, andnot 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_ sessionwill 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 majorannoyance (I hope). * Refined \c[onnect]'ion failures: Non-interactive scripts will terminate, even recursively. However, if the underlying sessionwas 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. Ihope 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, ittotally 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
> * 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, Pennsylvania19026
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
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
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
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
> 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