Re: 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 <mike(at)fuhr(dot)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

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Sat, Aug 13, 2005 at 10:33:55AM -0400, Tom Lane wrote:
> Michael Fuhr <mike(at)fuhr(dot)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(at)fuhr(dot)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(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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_authorization
transaction_isolation
transaction_read_only
vacuum_cost_delay
vacuum_cost_limit
vacuum_cost_page_dirty
vacuum_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_userlocks
zero_damaged_pages

PGC_INTERNAL
block_size
integer_datetimes
is_superuser
lc_collate
lc_ctype
max_function_args
max_identifier_length
max_index_keys
server_version
standard_compliant_strings

PGC_POSTMASTER
bonjour_name
config_file
custom_variable_classes
data_directory
external_pid_file
hba_file
ident_file
krb_caseins_users
krb_server_hostname
krb_server_keyfile
krb_srvname
listen_addresses
max_prepared_transactions
preload_libraries
redirect_stderr
silent_mode

PGC_SIGHUP
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
checkpoint_segments
checkpoint_timeout
checkpoint_warning
db_user_namespace
full_page_writes
log_directory
log_filename
log_hostname
log_line_prefix
log_rotation_age
log_rotation_size
log_truncate_on_rotation
pre_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(at)fuhr(dot)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(at)fuhr(dot)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(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Michael Fuhr <mike(at)fuhr(dot)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(at)fuhr(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)mit(dot)edu> wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)mit(dot)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(at)mit(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Sat, Aug 13, 2005 at 11:39:59AM -0400, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)pervasive(dot)com
Pervasive Software http://pervasive.com 512-569-9461

"Jim C. Nasby" <jnasby(at)pervasive(dot)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