Todo "claim": psql tab completion on schema names
I have been playing around with psql's "tab-completion.c" and have
something approaching a sane solution for tab expansion of
schema names. As this seems to fall under the todo item "Allow psql to do
table completion for SELECT * FROM schema_part and table completion for
SELECT * FROM schema_name" I would like if possible to "claim" this, at
least for a week or so.
If someone has a working solution already please let me know because
I have got quite involved in the file (there seem to be one or two areas
not directly related to schemas which could be improved as well) and I
wouldn't want to duplicate efforts.
In this respect couple of general questions:
- is there any reason why tab expansion of slash commands is
only implemented in a few cases? E.g. for \d but not \di ?
. is there any requirement to maintain any kind of backwards
compatibilty to pre 7.3 clients?
- pg_catalog.pg_table_is_visible() works on non-table relations
as well, right?
Ian Barwick
barwick@gmx.net
On Sat, 2003-02-15 at 18:53, Ian Barwick wrote:
I have been playing around with psql's "tab-completion.c" and have
something approaching a sane solution for tab expansion of
schema names. As this seems to fall under the todo item "Allow psql to do
table completion for SELECT * FROM schema_part and table completion for
SELECT * FROM schema_name" I would like if possible to "claim" this, at
least for a week or so.
I've been debating a mechanism which could build tab completion tables
based on the documentation for a while now -- and was going to give it a
try next week. If it works, that file would essentially disappear.
It doesn't really change what happens, just the approach. The end goal
being a backend independent psql.
In this respect couple of general questions:
- is there any reason why tab expansion of slash commands is
only implemented in a few cases? E.g. for \d but not \di ?
. is there any requirement to maintain any kind of backwards
compatibilty to pre 7.3 clients?
Post 7.3 launch most of these cases were cleaned up, not to say some
weren't missed. You might want to take a look at CVS-TIP sources. Feel
free to send in patches for ones that have been missed.
- pg_catalog.pg_table_is_visible() works on non-table relations
as well, right?
I would assume so, but haven't checked.
--
Rod Taylor <rbt@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
On Sunday 16 February 2003 01:10, Rod Taylor wrote:
I've been debating a mechanism which could build tab completion tables
based on the documentation for a while now -- and was going to give it a
try next week. If it works, that file would essentially disappear.
OK, will hold off and see what happens.
In this respect couple of general questions:
- is there any reason why tab expansion of slash commands is
only implemented in a few cases? E.g. for \d but not \di ?
. is there any requirement to maintain any kind of backwards
compatibilty to pre 7.3 clients?Post 7.3 launch most of these cases were cleaned up, not to say some
weren't missed. You might want to take a look at CVS-TIP sources.
It's what I have...
Feel
free to send in patches for ones that have been missed.
...what I meant is that after entering \d, TAB will produce a list of tables,
but \di does not produce a list of indexes, same for \dv etc. I see
no particular reason why this is so and can provide patches
if relevant.
Ian Barwick
barwick@gmx.net
On Sun, Feb 16, 2003 at 01:34:34AM +0100, Ian Barwick wrote:
On Sunday 16 February 2003 01:10, Rod Taylor wrote:
I've been debating a mechanism which could build tab completion tables
based on the documentation for a while now -- and was going to give it a
try next week. If it works, that file would essentially disappear.
Hmm, from slash commands, or from SQL grammar? Or both? How impossible would
it be to generate the tab-completion from the _grammar_ (for the SQL)
rather than from docs? Something I was musing about when adding cases to this
a month or so ago.
Feel
free to send in patches for ones that have been missed...what I meant is that after entering \d, TAB will produce a list of tables,
but \di does not produce a list of indexes, same for \dv etc. I see
no particular reason why this is so and can provide patches
if relevant.
Send in the patches: won't hurt, even if they get overridden by alter work -
who knows, Rod may get distracted and not complete the grand plan above.
In general, it's better to capture existing work than hold of for future,
better, implementations, for things like this (no backwards compatability
issues)
Ross
On Sat, 2003-02-15 at 19:49, Ross J. Reedstrom wrote:
On Sun, Feb 16, 2003 at 01:34:34AM +0100, Ian Barwick wrote:
On Sunday 16 February 2003 01:10, Rod Taylor wrote:
I've been debating a mechanism which could build tab completion tables
based on the documentation for a while now -- and was going to give it a
try next week. If it works, that file would essentially disappear.Hmm, from slash commands, or from SQL grammar? Or both? How impossible would
it be to generate the tab-completion from the _grammar_ (for the SQL)
rather than from docs? Something I was musing about when adding cases to this
a month or so ago.
Grammer would certainly be nicer but vastly more complicated. Parsing
the SGML shouldn't be overly difficult.
Perhaps I'll just clean up what I've done -- move describe.c to the
backend -- and see how to approach tab completion later.
Feel
free to send in patches for ones that have been missed...what I meant is that after entering \d, TAB will produce a list of tables,
but \di does not produce a list of indexes, same for \dv etc. I see
no particular reason why this is so and can provide patches
if relevant.Send in the patches: won't hurt, even if they get overridden by alter work -
who knows, Rod may get distracted and not complete the grand plan above.
Wouldn't be the first time ;)
--
Rod Taylor <rbt@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc