Thread: Autocomplete on Postgres7.4beta5 not working?
Hi all I'm esperiencing problem with the <TAB> autocomplete on postgres 7.4beta5: #select * from pg_l<TAB><TAB> and no suggestions out. On postgres 7.3.4: #select * from pg_l<TAB><TAB> pg_language pg_largeobject pg_listener pg_locks am I wrong ? regards Gaetano Mendola
Gaetano Mendola <mendola@bigfoot.com> writes:
> I'm esperiencing problem with the <TAB> autocomplete on
> postgres 7.4beta5:
> #select * from pg_l<TAB><TAB>
> and no suggestions out.
This appears to have been a deliberate change:
2003-03-27 11:45 momjian
* src/bin/psql/tab-complete.c: Attached are two patches for psql'stab-completion.c. [snip]
Note that tables, indexes, views and sequences relations in the'pg_catalog' namespace are excluded even though they are
inthecurrent search path. I found not doing this produced annoyingbehaviour when expanding names beginning with 'p'.
Peoplewho workwith system tables a lot may not like this though; I can look foranother solution if necessary.Ian
Barwick
AFAICT there was no discussion about this issue when the patch was
proposed and applied. But now that the point is raised I have to say
that I don't like this change. I don't think system catalogs should be
excluded from tab completion. They never were before 7.4, and I have
not seen anyone complaining about that, other than Ian.
Comments anyone?
regards, tom lane
Tom Lane wrote: > This appears to have been a deliberate change: > > 2003-03-27 11:45 momjian > > * src/bin/psql/tab-complete.c: Attached are two patches for psql's > tab-completion.c. > [snip] > > Note that tables, indexes, views and sequences relations in the > 'pg_catalog' namespace are excluded even though they are in the > current search path. I found not doing this produced annoying > behaviour when expanding names beginning with 'p'. People who work > with system tables a lot may not like this though; I can look for > another solution if necessary. > > Ian Barwick > > AFAICT there was no discussion about this issue when the patch was > proposed and applied. But now that the point is raised I have to say > that I don't like this change. I don't think system catalogs should be > excluded from tab completion. They never were before 7.4, and I have > not seen anyone complaining about that, other than Ian. > > Comments anyone? No one commented on it so it was applied --- now that we have two people who don't like it, seems we should back it out. -- 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:
> Tom Lane wrote:
>> AFAICT there was no discussion about this issue when the patch was
>> proposed and applied. But now that the point is raised I have to say
>> that I don't like this change. I don't think system catalogs should be
>> excluded from tab completion. They never were before 7.4, and I have
>> not seen anyone complaining about that, other than Ian.
>>
>> Comments anyone?
> No one commented on it so it was applied --- now that we have two people
> who don't like it, seems we should back it out.
Not the whole patch, certainly, since it added a bunch of other good
stuff. I just want to take out the discrimination against pg_catalog.
(BTW, the code also discriminates against pg_toast, but that part I
don't have a problem with.)
regards, tom lane
On Tuesday 28 October 2003 22:48, Tom Lane wrote: > AFAICT there was no discussion about this issue when the patch was > proposed and applied. But now that the point is raised I have to say > that I don't like this change. I don't think system catalogs should be > excluded from tab completion. They never were before 7.4, and I have > not seen anyone complaining about that, other than Ian. > > Comments anyone? Guilty as charged? ;-) Just to clarify, the patch enables tab completion for catalog relations as long as the schema name pg_catalog is prepended. E.g. \d pg_c[tab].[tab] will get expansion for everything in pg_catalog. ISTR I found it very irritating that without this restriction \d p[tab] produces a very large number of selections for "normal" database work. Looking at a current database, I have about a dozen of relations beginning with p in the search path which I access with tab expansion frequently and I'm sure it would annoy me intensely if I got all the system tables as well every time. Mind you that's only my personal preference, I thought it might be unpopular but as no one has commented since... I can submit a correction but not today or tomorrow. Ian Barwick barwick@gmx.net
Alvaro Herrera Munoz <alvherre@dcc.uchile.cl> writes:
> I found it very irritating at first, but when I discovered that I could
> tab my way to syscatalogs by using "pg_catalog." as prefix, I started
> feeling it was actually a nice behavior.
Hm. Okay, Ian isn't completely alone then ;-)
I tried out that approach just now, though, and found that I still had
to type at least "pg_c" before I could get any tab completion help at
all. Another odd thing was that after completing "pg_catalog.", it
wouldn't go any further --- one must type "p" here, even though all the
possible completions begin "pg_". (Possibly that could be fixed, but
I don't know readline's behavior well enough to be sure.) So that's
five typed characters and two tabs before one starts getting into the
system catalogs. That seems like a lot of typing. If Ian were willing
to type one more character of his p-something table names before hitting
tab (I assume he's not calling them pg-something), then he'd not have a
problem with the availability of tab completion for system catalogs.
I think saving one keystroke for p-something user tables is a poor
return for requiring seven keystrokes for system catalogs.
Anyway, it seems like we need a vote to see how many people prefer
each choice.
regards, tom lane
Alvaro Herrera Munoz wrote: > On Tue, Oct 28, 2003 at 04:48:59PM -0500, Tom Lane wrote: >>AFAICT there was no discussion about this issue when the patch was >>proposed and applied. But now that the point is raised I have to say >>that I don't like this change. I don't think system catalogs should be >>excluded from tab completion. They never were before 7.4, and I have >>not seen anyone complaining about that, other than Ian. > > I found it very irritating at first, but when I discovered that I could > tab my way to syscatalogs by using "pg_catalog." as prefix, I started > feeling it was actually a nice behavior. > I found it similarly irritating at first, and it continues to irritate me. But that may be because I use system tables more frequently than the average Joe ;-) I guess I'd be happy to see tab completion reinstated for system tables (except toast tables as Tom suggested nearby), but I don't feel particularly zealous about it. Joe
On Tuesday 28 October 2003 23:47, Tom Lane wrote: > Alvaro Herrera Munoz <alvherre@dcc.uchile.cl> writes: > > I found it very irritating at first, but when I discovered that I could > > tab my way to syscatalogs by using "pg_catalog." as prefix, I started > > feeling it was actually a nice behavior. > > Hm. Okay, Ian isn't completely alone then ;-) > > I tried out that approach just now, though, and found that I still had > to type at least "pg_c" before I could get any tab completion help at > all. Another odd thing was that after completing "pg_catalog.", it > wouldn't go any further --- one must type "p" here, even though all the > possible completions begin "pg_". (Possibly that could be fixed, but > I don't know readline's behavior well enough to be sure.) I'm not sure whether it's intended or not, but explicitly adding pg_catalog to the search path alleviates this. > So that's > five typed characters and two tabs before one starts getting into the > system catalogs. That seems like a lot of typing. If Ian were willing > to type one more character of his p-something table names before hitting > tab (I assume he's not calling them pg-something), Err ;-) db=> \d p page_template_cache pg_ts_cfg_pkey page_template_cache_ov_idx pg_ts_cfgmap page_template_cache_pkey pg_ts_cfgmap_pkey page_template_cache_template_idx pg_ts_dict pg_catalog. pg_ts_dict_pkey pg_temp_1. pg_ts_parser pg_toast. pg_ts_parser_pkey pg_ts_cfg public. (The pg_ts_% are all from tsearch2 BTW. Though, they`re all in a schema of their own so explicitly addressing them would work equally well too). > then he'd not have a > problem with the availability of tab completion for system catalogs. I'm sure I can live with that (one more character), at least until I finish the brainwave input extension ;-). Ian Barwick barwick@gmx.net
> Anyway, it seems like we need a vote to see how many people prefer
> each choice.
I say leave it the way it is. If you want system table tab completion,
simply:
ALTER USER ... SET search_path = pg_catalog,...;
I would like to see the information_schema be a part of the default
search_path -- but I can do that myself.
Ian Barwick <barwick@gmx.net> writes:
> On Tuesday 28 October 2003 23:47, Tom Lane wrote:
>> Another odd thing was that after completing "pg_catalog.", it
>> wouldn't go any further --- one must type "p" here, even though all the
>> possible completions begin "pg_". (Possibly that could be fixed, but
>> I don't know readline's behavior well enough to be sure.)
> I'm not sure whether it's intended or not, but explicitly adding
> pg_catalog to the search path alleviates this.
It turns out that I unintentionally broke that a few days ago while
adding quote_ident() calls. I've repaired that damage, so now you can
gopg_c<TAB><TAB>
and getpg_catalog.pg_
which is one less keystroke than I claimed before. I still think it's
too many though ...
regards, tom lane
Rod Taylor <rbt@rbt.ca> writes:
> I say leave it the way it is. If you want system table tab completion,
> simply:
> ALTER USER ... SET search_path =3D pg_catalog,...;
Unfortunately, that *does not* affect the tab-completion behavior;
it will still not offer the system catalogs as completions unless
you explicitly prefix "pg_catalog.".
regards, tom lane
On Tue, 2003-10-28 at 18:49, Tom Lane wrote: > Rod Taylor <rbt@rbt.ca> writes: > > I say leave it the way it is. If you want system table tab completion, > > simply: > > ALTER USER ... SET search_path =3D pg_catalog,...; > > Unfortunately, that *does not* affect the tab-completion behavior; > it will still not offer the system catalogs as completions unless > you explicitly prefix "pg_catalog.". Very well.. Would it be enough simply to fix it so it does work? Remove the S functionality and allow pg_catalog to work like a normal schema.
On Tue, Oct 28, 2003 at 04:48:59PM -0500, Tom Lane wrote: > AFAICT there was no discussion about this issue when the patch was > proposed and applied. But now that the point is raised I have to say > that I don't like this change. I don't think system catalogs should be > excluded from tab completion. They never were before 7.4, and I have > not seen anyone complaining about that, other than Ian. I found it very irritating at first, but when I discovered that I could tab my way to syscatalogs by using "pg_catalog." as prefix, I started feeling it was actually a nice behavior. -- Alvaro Herrera (<alvherre[@]dcc.uchile.cl>) "Coge la flor que hoy nace alegre, ufana. �Qui�n sabe si nacera otra ma�ana?"
On Tue, 28 Oct 2003, Tom Lane wrote: > Rod Taylor <rbt@rbt.ca> writes: > > I say leave it the way it is. If you want system table tab completion, > > simply: > > ALTER USER ... SET search_path =3D pg_catalog,...; > > Unfortunately, that *does not* affect the tab-completion behavior; > it will still not offer the system catalogs as completions unless > you explicitly prefix "pg_catalog.". It seems a good compromise then would be that if "pg_catalog" is in your search path, then do the old fashioned completion, i.e. p<tab> will list everything in both pg_catalog and the other schemas in your search path. Afterall, the system catalog kind of "hitchhikes" along for a ride in your search path. Most users aren't interested in the system catalogs, so having them suddenly show up when you just wanted the phonebook table is kinda a bother for them. Is it possible to remove the implicit search path of pg_catalog from a psql session without it breaking lots of stuff? If not, then it's kind of ugly to the user to have no way to get the system from proffering pg_catalog tables when they have no interest in them. If so, then why make it part of the default?
> AFAICT there was no discussion about this issue when the patch was > proposed and applied. But now that the point is raised I have to say > that I don't like this change. I don't think system catalogs should be > excluded from tab completion. They never were before 7.4, and I have > not seen anyone complaining about that, other than Ian. > > Comments anyone? I had noticed that, but I had gotten used to it. I'm not fussed particularly either way, really... Chris
This now works in current CVS and will be in 7.4 final:
test=> select * from pg_l
pg_language pg_largeobject pg_listener pg_locks
---------------------------------------------------------------------------
Gaetano Mendola wrote:
> Hi all
> I'm esperiencing problem with the <TAB> autocomplete on
> postgres 7.4beta5:
>
> #select * from pg_l<TAB><TAB>
> and no suggestions out.
>
>
> On postgres 7.3.4:
>
> #select * from pg_l<TAB><TAB>
> pg_language pg_largeobject pg_listener pg_locks
>
>
>
> am I wrong ?
>
>
>
> regards
> Gaetano Mendola
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
--
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, Pennsylvania 19073
Bruce Momjian wrote: > This now works in current CVS and will be in 7.4 final: Thank you. regards Gaetano Mendola