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
Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
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 [EMAIL PROTECTED] writes:
What about going
Jim C. Nasby [EMAIL PROTECTED] 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
On 13 Aug 2005 21:42:45 -0400, Greg Stark [EMAIL PROTECTED] wrote:
Tom Lane [EMAIL PROTECTED] 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
Greg Stark [EMAIL PROTECTED] 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
Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] 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
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
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
On Sat, Aug 13, 2005 at 10:33:55AM -0400, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] 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
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
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
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
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
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
Michael Fuhr [EMAIL PROTECTED] 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),
On Sat, Aug 13, 2005 at 12:41:51PM -0400, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] 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
Tom Lane [EMAIL PROTECTED] writes:
Michael Fuhr [EMAIL PROTECTED] 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
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
Michael Fuhr [EMAIL PROTECTED] 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
Tom Lane [EMAIL PROTECTED] 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
20 matches
Mail list logo
