Re: [HACKERS] Autocomplete <TAB> 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(at)bigfoot(dot)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'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?

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(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 Tue, 28 Oct 2003, Tom Lane wrote:

> 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?

I also would expect any relations I can see to be picked up by tab
completion.

Jon

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)gmx(dot)net

Tom Lane wrote:

>Gaetano Mendola <mendola(at)bigfoot(dot)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'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?
>
>

Might be better to:

1. make it a settable option

and/or

2. include catalog objects in expansion iff we are expanding "pg_" +
optional suffix (probably best of both worlds).

I rarely use completion in this way so I could be an unrepresentative
user, though :-)

cheers

andrew

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[(at)]dcc(dot)uchile(dot)cl>)
"Coge la flor que hoy nace alegre, ufana. Quin sabe si nacera otra maana?"

I think I'm missing something. Why are pg_catalog.* tables in my search path
at all? My search path seems to be set to $user,public. is pg_catalog
implicitly appended there?

--
greg

Alvaro Herrera Munoz <alvherre(at)dcc(dot)uchile(dot)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

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> 2. include catalog objects in expansion iff we are expanding "pg_" +
> optional suffix (probably best of both worlds).

Hmm, that might be an okay compromise. Not sure how hard it is to
implement ...

regards, tom lane

Greg Stark <gsstark(at)mit(dot)edu> writes:
> I think I'm missing something. Why are pg_catalog.* tables in my search path
> at all? My search path seems to be set to $user,public. is pg_catalog
> implicitly appended there?

Yes. See TFM:
http://developer.postgresql.org/docs/postgres/ddl-schemas.html
particularly section 5.8.5.

regards, tom lane

On Tuesday 28 October 2003 23:47, Tom Lane wrote:
> Alvaro Herrera Munoz <alvherre(at)dcc(dot)uchile(dot)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(at)gmx(dot)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(at)gmx(dot)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
go
pg_c<TAB><TAB>
and get
pg_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(at)rbt(dot)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, 28 Oct 2003, Tom Lane wrote:

> Rod Taylor <rbt(at)rbt(dot)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?

On Tue, 2003-10-28 at 18:49, Tom Lane wrote:
> Rod Taylor <rbt(at)rbt(dot)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.

"scott.marlowe" <scott(dot)marlowe(at)ihs(dot)com> writes:
> Is it possible to remove the implicit search path of pg_catalog from a
> psql session without it breaking lots of stuff?

Do you consider "+", "count()", etc to be important stuff?

regards, tom lane

On Tue, 28 Oct 2003, Tom Lane wrote:

> "scott.marlowe" <scott(dot)marlowe(at)ihs(dot)com> writes:
> > Is it possible to remove the implicit search path of pg_catalog from a
> > psql session without it breaking lots of stuff?
>
> Do you consider "+", "count()", etc to be important stuff?

Me, hardly ever use them :-) So I can assume that removing the implicit
pg_catalog from the search path is a "bad thing."

In that case, does my proposed solution of having to implicitly include
pg_catalog in your search path to get it to be seen by tab completion as
just another schema make sense?

> 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

On Tue, 2003-10-28 at 19:34, scott.marlowe wrote:
> On Tue, 28 Oct 2003, Tom Lane wrote:
>
> > "scott.marlowe" <scott(dot)marlowe(at)ihs(dot)com> writes:
> > > Is it possible to remove the implicit search path of pg_catalog from a
> > > psql session without it breaking lots of stuff?
> >
> > Do you consider "+", "count()", etc to be important stuff?
>
> Me, hardly ever use them :-) So I can assume that removing the implicit
> pg_catalog from the search path is a "bad thing."

From the search_path certainly -- but we can we teach the difference
between implicit and explicit to the *is_visible functions?

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> 2. include catalog objects in expansion iff we are expanding "pg_" +
> optional suffix (probably best of both worlds).

That seems like the best compromise position anyone offered, so I have
made the code work that way.

regards, tom lane

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(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 wrote:

> This now works in current CVS and will be in 7.4 final:

Thank you.

regards
Gaetano Mendola