Обсуждение: psql SET/RESET/SHOW tab completion
Would anybody object to a patch to update psql's tab completion for SET/RESET/SHOW to include everything that SHOW shows for a superuser? I count about 65 variables that SHOW shows that are missing from pgsql_variables in tab-complete.c. Does the list intentionally omit certain variables? The comment mentions that the list "should match USERSET and possibly SUSET," but I'm thinking it would be useful to include everything SHOWable. In any case, a few USERSET variables like check_function_bodies and escape_string_warning are missing, so I'd like to add at least those. -- Michael Fuhr
Michael Fuhr wrote: > Would anybody object to a patch to update psql's tab completion for > SET/RESET/SHOW to include everything that SHOW shows for a superuser? > > I count about 65 variables that SHOW shows that are missing from > pgsql_variables in tab-complete.c. Does the list intentionally > omit certain variables? The comment mentions that the list "should > match USERSET and possibly SUSET," but I'm thinking it would be > useful to include everything SHOWable. In any case, a few USERSET > variables like check_function_bodies and escape_string_warning are > missing, so I'd like to add at least those. Makes sense. We were thinking mostly of SET when we made the list, but SHOW would be used in a lot of cases we don't handle now. Ideally we could have that list auto-generated somehow. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Michael Fuhr <mike@fuhr.org> writes:
> I count about 65 variables that SHOW shows that are missing from
> pgsql_variables in tab-complete.c. Does the list intentionally
> omit certain variables?
It's intentional that the tab completion not list every single variable;
I think if it did, it would be less useful not more so. However the
decisions about which to omit have been less consistent than they
perhaps should be, and I'm sure there were some omitted purely through
oversight. It would be good to go through the whole list and see
exactly what's missing or superfluous.
regards, tom lane
On Sat, Aug 13, 2005 at 10:33:55AM -0400, Tom Lane wrote: > Michael Fuhr <mike@fuhr.org> writes: > > I count about 65 variables that SHOW shows that are missing from > > pgsql_variables in tab-complete.c. Does the list intentionally > > omit certain variables? > > It's intentional that the tab completion not list every single variable; > I think if it did, it would be less useful not more so. However the > decisions about which to omit have been less consistent than they > perhaps should be, and I'm sure there were some omitted purely through > oversight. It would be good to go through the whole list and see > exactly what's missing or superfluous. Here's the list I came up with -- variables that SHOW shows that aren't in psql's completion list. archive_command authentication_timeout autovacuum autovacuum_analyze_scale_factor autovacuum_analyze_threshold autovacuum_naptime autovacuum_vacuum_cost_delay autovacuum_vacuum_cost_limit autovacuum_vacuum_scale_factor autovacuum_vacuum_threshold bgwriter_all_maxpages bgwriter_all_percent bgwriter_delay bgwriter_lru_maxpages bgwriter_lru_percent block_size bonjour_name check_function_bodies checkpoint_segments checkpoint_timeout checkpoint_warning config_file custom_variable_classes data_directory db_user_namespace escape_string_warning external_pid_file full_page_writes hba_file ident_file integer_datetimes krb_caseins_users krb_server_hostname krb_server_keyfile krb_srvname lc_collate lc_ctype listen_addresses log_connections log_directory log_disconnections log_filename log_hostname log_line_prefix log_rotation_age log_rotation_size log_truncate_on_rotation max_function_args max_identifier_length max_index_keys max_prepared_transactions pre_auth_delay preload_libraries redirect_stderr server_version silent_mode standard_compliant_strings transaction_isolation transaction_read_only vacuum_cost_delay vacuum_cost_limit vacuum_cost_page_dirty vacuum_cost_page_hit vacuum_cost_page_miss zero_damaged_pages -- Michael Fuhr
I am wondering if is worth managing which items should be displayed or not, and if we should just give up and display them all. The GUC system is just too dynamic. --------------------------------------------------------------------------- Michael Fuhr wrote: > On Sat, Aug 13, 2005 at 10:33:55AM -0400, Tom Lane wrote: > > Michael Fuhr <mike@fuhr.org> writes: > > > I count about 65 variables that SHOW shows that are missing from > > > pgsql_variables in tab-complete.c. Does the list intentionally > > > omit certain variables? > > > > It's intentional that the tab completion not list every single variable; > > I think if it did, it would be less useful not more so. However the > > decisions about which to omit have been less consistent than they > > perhaps should be, and I'm sure there were some omitted purely through > > oversight. It would be good to go through the whole list and see > > exactly what's missing or superfluous. > > Here's the list I came up with -- variables that SHOW shows that > aren't in psql's completion list. > > archive_command > authentication_timeout > autovacuum > autovacuum_analyze_scale_factor > autovacuum_analyze_threshold > autovacuum_naptime > autovacuum_vacuum_cost_delay > autovacuum_vacuum_cost_limit > autovacuum_vacuum_scale_factor > autovacuum_vacuum_threshold > bgwriter_all_maxpages > bgwriter_all_percent > bgwriter_delay > bgwriter_lru_maxpages > bgwriter_lru_percent > block_size > bonjour_name > check_function_bodies > checkpoint_segments > checkpoint_timeout > checkpoint_warning > config_file > custom_variable_classes > data_directory > db_user_namespace > escape_string_warning > external_pid_file > full_page_writes > hba_file > ident_file > integer_datetimes > krb_caseins_users > krb_server_hostname > krb_server_keyfile > krb_srvname > lc_collate > lc_ctype > listen_addresses > log_connections > log_directory > log_disconnections > log_filename > log_hostname > log_line_prefix > log_rotation_age > log_rotation_size > log_truncate_on_rotation > max_function_args > max_identifier_length > max_index_keys > max_prepared_transactions > pre_auth_delay > preload_libraries > redirect_stderr > server_version > silent_mode > standard_compliant_strings > transaction_isolation > transaction_read_only > vacuum_cost_delay > vacuum_cost_limit > vacuum_cost_page_dirty > vacuum_cost_page_hit > vacuum_cost_page_miss > zero_damaged_pages > > -- > Michael Fuhr > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I am wondering if is worth managing which items should be displayed or
> not, and if we should just give up and display them all. The GUC system
> is just too dynamic.
Not sure. I count 98 GUC variables currently listed in tab-complete.c,
and 162 rows in pg_settings. So listing them all would be a pretty
sizable increase (65%) in what's already an unwieldy list. I would
prefer to see some thought given to removing useless entries ... eg,
I doubt anyone needs tab completion for "trace_notify" or "wal_debug".
However, if you favor a "no thought required" approach, listing 'em
all is certainly the path of least resistance. I'm just dubious that
that maximizes the usefulness of tab completion.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I am wondering if is worth managing which items should be displayed or > > not, and if we should just give up and display them all. The GUC system > > is just too dynamic. > > Not sure. I count 98 GUC variables currently listed in tab-complete.c, > and 162 rows in pg_settings. So listing them all would be a pretty > sizable increase (65%) in what's already an unwieldy list. I would > prefer to see some thought given to removing useless entries ... eg, > I doubt anyone needs tab completion for "trace_notify" or "wal_debug". > > However, if you favor a "no thought required" approach, listing 'em > all is certainly the path of least resistance. I'm just dubious that > that maximizes the usefulness of tab completion. Can't we just pull these from pg_settings, with relivant restrictions on what we list. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Sat, Aug 13, 2005 at 09:25:34AM -0600, Michael Fuhr wrote: > > Here's the list I came up with -- variables that SHOW shows that > aren't in psql's completion list. Here's the list broken down by context: PGC_USERSET autocommit check_function_bodies debug_assertions escape_string_warning exit_on_error role session_authorizationtransaction_isolation transaction_read_only vacuum_cost_delay vacuum_cost_limit vacuum_cost_page_dirtyvacuum_cost_page_hit vacuum_cost_page_miss PGC_SUSET debug_deadlocks log_btree_build_stats trace_locks trace_lock_oidmin trace_lock_table trace_lwlocks trace_userlockszero_damaged_pages PGC_INTERNAL block_size integer_datetimes is_superuser lc_collate lc_ctype max_function_args max_identifier_length max_index_keysserver_version standard_compliant_strings PGC_POSTMASTER bonjour_name config_file custom_variable_classes data_directory external_pid_file hba_file ident_file krb_caseins_userskrb_server_hostname krb_server_keyfile krb_srvname listen_addresses max_prepared_transactions preload_librariesredirect_stderr silent_mode PGC_SIGHUP archive_command authentication_timeout autovacuum autovacuum_analyze_scale_factor autovacuum_analyze_thresholdautovacuum_naptime autovacuum_vacuum_cost_delay autovacuum_vacuum_cost_limit autovacuum_vacuum_scale_factorautovacuum_vacuum_threshold bgwriter_all_maxpages bgwriter_all_percent bgwriter_delay bgwriter_lru_maxpagesbgwriter_lru_percent checkpoint_segments checkpoint_timeout checkpoint_warning db_user_namespace full_page_writeslog_directory log_filename log_hostname log_line_prefix log_rotation_age log_rotation_size log_truncate_on_rotationpre_auth_delay PGC_BACKEND log_connections log_disconnections -- Michael Fuhr
On Sat, Aug 13, 2005 at 11:39:59AM -0400, Tom Lane wrote: > I count 98 GUC variables currently listed in tab-complete.c, > and 162 rows in pg_settings. Is 162 a typo or are you working on something that hasn't been committed yet? I see 161 in the latest code. template1=# SELECT count(*) FROM pg_settings;count ------- 161 (1 row) -- Michael Fuhr
Michael Fuhr <mike@fuhr.org> writes:
> Is 162 a typo or are you working on something that hasn't been
> committed yet? I see 161 in the latest code.
Uh, I get 162 ... and no I don't have any uncommitted changes ATM.
The last change I see in guc.c was two days ago (latest autovacuum
additions), so that should certainly have settled out. Do you want
to send me your results (off-list), and I'll compare to what I get?
regards, tom lane
On Sat, Aug 13, 2005 at 12:41:51PM -0400, Tom Lane wrote: > Michael Fuhr <mike@fuhr.org> writes: > > Is 162 a typo or are you working on something that hasn't been > > committed yet? I see 161 in the latest code. > > Uh, I get 162 ... and no I don't have any uncommitted changes ATM. I found the difference: one of my boxes is missing debug_assertions. I had removed --enable-cassert from my configure script while doing some performance tests and never put it back (I had noticed that VACUUM was quite slow on that box and found that it was due to the assertion checks). -- Michael Fuhr
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Michael Fuhr <mike@fuhr.org> writes:
>> Is 162 a typo or are you working on something that hasn't been
>> committed yet? I see 161 in the latest code.
> Uh, I get 162 ... and no I don't have any uncommitted changes ATM.
Oh, I bet I know what it is: I built with --enable-cassert which
creates "debug_assertions" as a GUC variable.
regards, tom lane
On Sat, Aug 13, 2005 at 11:04:18AM -0600, Michael Fuhr wrote: > I had removed --enable-cassert from my configure script while doing > some performance tests and never put it back (I had noticed that > VACUUM was quite slow on that box and found that it was due to the > assertion checks). BTW, here are the results of those tests: a VACUUM ANALYZE of template1 without --enable-cassert takes about 830ms on my box. With --enable-cassert it takes about 24200ms, regardless of the debug_assertions setting. -- Michael Fuhr
Michael Fuhr <mike@fuhr.org> writes:
> BTW, here are the results of those tests: a VACUUM ANALYZE of
> template1 without --enable-cassert takes about 830ms on my box.
> With --enable-cassert it takes about 24200ms, regardless of the
> debug_assertions setting.
I believe that in current sources, the main cost of --enable-cassert
comes from the memory clobber checks it enables, which are for the
most part performed regardless of debug_assertions.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > However, if you favor a "no thought required" approach, listing 'em > all is certainly the path of least resistance. I'm just dubious that > that maximizes the usefulness of tab completion. I'm not sure if you're interested, but my 2c speaking as a user would be for tab completion to include all variables. I often hit tab completion in new programs just to find out what's out there and would take something missing to be positive proof it didn't exist. -- greg
On 13 Aug 2005 21:42:45 -0400, Greg Stark <gsstark@mit.edu> wrote: > Tom Lane <tgl@sss.pgh.pa.us> writes: > > However, if you favor a "no thought required" approach, listing 'em > > all is certainly the path of least resistance. I'm just dubious that > > that maximizes the usefulness of tab completion. > I'm not sure if you're interested, but my 2c speaking as a user would be for > tab completion to include all variables. I often hit tab completion in new > programs just to find out what's out there and would take something missing to > be positive proof it didn't exist. Oh, I usually do the same thing. I guess my approach could summarized as: I assume tab-completion is not too smart -- it just completes one of valid values. And at the times where tab-completion is smart, it is smart and configurable -- as ZSH tab-completion. And were PostgreSQL's tab-completion go "the smart way" I would be for adding a GUC which allowed to fine-grain what it actually gives (all variables, settable variables, 'vacuum%' and 'enable%' variables, etc. ;))). Regards, Dawid
Greg Stark <gsstark@mit.edu> writes:
> I'm not sure if you're interested, but my 2c speaking as a user would be for
> tab completion to include all variables.
OK, I'm clearly outvoted on this one. How about we make SHOW
tab-complete everything listed in pg_settings, while SET/RESET
tab-complete everything that's USERSET or SUSET?
(We could probably even make it suppress SUSET if you aren't superuser,
but I'm not sure if that's worth the trouble.)
regards, tom lane
Tom Lane wrote: > Greg Stark <gsstark@mit.edu> writes: > > I'm not sure if you're interested, but my 2c speaking as a user would be for > > tab completion to include all variables. > > OK, I'm clearly outvoted on this one. How about we make SHOW > tab-complete everything listed in pg_settings, while SET/RESET > tab-complete everything that's USERSET or SUSET? > > (We could probably even make it suppress SUSET if you aren't superuser, > but I'm not sure if that's worth the trouble.) Yea, that's what I was thinking. Not sure if the superuser check is _too_ smart. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Sat, Aug 13, 2005 at 11:39:59AM -0400, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I am wondering if is worth managing which items should be displayed or > > not, and if we should just give up and display them all. The GUC system > > is just too dynamic. > > Not sure. I count 98 GUC variables currently listed in tab-complete.c, > and 162 rows in pg_settings. So listing them all would be a pretty > sizable increase (65%) in what's already an unwieldy list. I would > prefer to see some thought given to removing useless entries ... eg, > I doubt anyone needs tab completion for "trace_notify" or "wal_debug". > > However, if you favor a "no thought required" approach, listing 'em > all is certainly the path of least resistance. I'm just dubious that > that maximizes the usefulness of tab completion. What about going the route of tcsh (and I'm sure others) where ^D shows you what your options are for tab-completion? This makes it much easier to find the option you're looking for. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com 512-569-9461
Learn something new every day... (and yeah, I never understood why tcsh uses ^D, especially that if you do ^D on a newline you disconnect...) -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com 512-569-9461 > -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: Monday, August 22, 2005 2:58 PM > To: Jim Nasby > Cc: Bruce Momjian; Michael Fuhr; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] psql SET/RESET/SHOW tab completion > > > "Jim C. Nasby" <jnasby@pervasive.com> writes: > > What about going the route of tcsh (and I'm sure others) > where ^D shows > > you what your options are for tab-completion? This makes it > much easier > > to find the option you're looking for. > > readline does that already ... just not with ^D (which seems a dang > weird choice for it anyway). Try tab twice. > > regards, tom lane >
"Jim C. Nasby" <jnasby@pervasive.com> writes:
> What about going the route of tcsh (and I'm sure others) where ^D shows
> you what your options are for tab-completion? This makes it much easier
> to find the option you're looking for.
readline does that already ... just not with ^D (which seems a dang
weird choice for it anyway). Try tab twice.
regards, tom lane