Обсуждение: 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