Обсуждение: psql Week 2

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

psql Week 2

От
Peter Eisentraut
Дата:
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



Re: [HACKERS] psql Week 2

От
Bruce Momjian
Дата:
> * 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
 


Re: [HACKERS] psql Week 2

От
Tatsuo Ishii
Дата:
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



Re: [HACKERS] psql Week 2

От
Tom Lane
Дата:
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


Re: [HACKERS] psql Week 2

От
Peter Eisentraut
Дата:
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



Re: [HACKERS] psql Week 2

От
Peter Eisentraut
Дата:
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



Re: [HACKERS] psql Week 2

От
Tatsuo Ishii
Дата:
> 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