"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 dan
nal 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"
On Sat, Aug 13, 2005 at 11:39:59AM -0400, Tom Lane wrote:
> Bruce Momjian 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 variable
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,
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
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 comp
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 wou
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
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
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 bu
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
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 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_
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_warnin
Tom Lane wrote:
> Bruce Momjian 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,
> an
Bruce Momjian 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
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:55A
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 ta
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
>
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 completion not list every single variable;
I think if it did, it wou
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 co
21 matches
Mail list logo
