Thread: tab completion for setting search_path
I've been working with an app that uses a schema name whose spelling is hard to type, and the lack of tab completion for "SET search_path TO" was bugging me. So see attached.
I filter out the system schemata, but not public.
For commit fest next.
Cheers,
Jeff
On Friday, May 2, 2014, Jeff Janes <jeff.janes@gmail.com> wrote:
I've been working with an app that uses a schema name whose spelling is hard to type, and the lack of tab completion for "SET search_path TO" was bugging me. So see attached.I filter out the system schemata, but not public.For commit fest next.
Once more, with attachment....
Cheers,
Jeff
Attachment
On 2014-05-03 00:13:45 -0700, Jeff Janes wrote:
> On Friday, May 2, 2014, Jeff Janes <jeff.janes@gmail.com> wrote:
>
> > I've been working with an app that uses a schema name whose spelling is
> > hard to type, and the lack of tab completion for "SET search_path TO" was
> > bugging me. So see attached.
> >
> > I filter out the system schemata, but not public.
That'd be nice.
> diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
> new file mode 100644
> index 6d26ffc..dec3d4a
> *** a/src/bin/psql/tab-complete.c
> --- b/src/bin/psql/tab-complete.c
> *************** psql_completion(const char *text, int st
> *** 3230,3235 ****
> --- 3230,3242 ----
>
> COMPLETE_WITH_LIST(my_list);
> }
> + else if (pg_strcasecmp(prev2_wd, "search_path") == 0)
> + {
> + COMPLETE_WITH_QUERY(Query_for_list_of_schemas
> + " AND nspname not like 'pg\\_%%' "
> + " AND nspname not like 'information_schema' "
> + " UNION SELECT 'DEFAULT' ");
> + }
Why should we exclude system schemata? That seems more likely to be
confusing than helpful? I can see a point in excluding another backend's
temp tables, but otherwise?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
--On 3. Mai 2014 10:11:33 +0200 Andres Freund <andres@2ndquadrant.com>
wrote:
>> diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
>> new file mode 100644
>> index 6d26ffc..dec3d4a
>> *** a/src/bin/psql/tab-complete.c
>> --- b/src/bin/psql/tab-complete.c
>> *************** psql_completion(const char *text, int st
>> *** 3230,3235 ****
>> --- 3230,3242 ----
>>
>> COMPLETE_WITH_LIST(my_list);
>> }
>> + else if (pg_strcasecmp(prev2_wd, "search_path") == 0)
>> + {
>> + COMPLETE_WITH_QUERY(Query_for_list_of_schemas
>> + " AND nspname not like 'pg\\_%%' "
>> + " AND nspname not like 'information_schema' "
>> + " UNION SELECT 'DEFAULT' ");
>> + }
>
> Why should we exclude system schemata? That seems more likely to be
> confusing than helpful? I can see a point in excluding another backend's
> temp tables, but otherwise?
I put my hands on this a while ago, too, but had a different notion in
mind, which schema the completion should select. I came up with the
following:
<http://git.postgresql.org/gitweb/?p=users/bernd/postgres.git;a=commitdiff;h=03fd00cd190e8b529efeec1a1bb038454fb0b05f>
Just complete to a schema someone has CREATE or USAGE privs. However, the
reason i stopped working on it was that i really want to have a completion
to a list of schemas as well and i couldn't figure a good and easy way to
do this atm.
--
Thanks
Bernd
On Sat, May 3, 2014 at 1:11 AM, Andres Freund <andres@2ndquadrant.com> wrote:
On 2014-05-03 00:13:45 -0700, Jeff Janes wrote:That'd be nice.
> On Friday, May 2, 2014, Jeff Janes <jeff.janes@gmail.com> wrote:
>
> > I've been working with an app that uses a schema name whose spelling is
> > hard to type, and the lack of tab completion for "SET search_path TO" was
> > bugging me. So see attached.
> >
> > I filter out the system schemata, but not public.
> diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
> new file mode 100644
> index 6d26ffc..dec3d4a
> *** a/src/bin/psql/tab-complete.c
> --- b/src/bin/psql/tab-complete.c
> *************** psql_completion(const char *text, int st
> *** 3230,3235 ****
> --- 3230,3242 ----
>
> COMPLETE_WITH_LIST(my_list);
> }
> + else if (pg_strcasecmp(prev2_wd, "search_path") == 0)
> + {
> + COMPLETE_WITH_QUERY(Query_for_list_of_schemas
> + " AND nspname not like 'pg\\_%%' "
> + " AND nspname not like 'information_schema' "
> + " UNION SELECT 'DEFAULT' ");
> + }
Why should we exclude system schemata? That seems more likely to be
confusing than helpful? I can see a point in excluding another backend's
temp tables, but otherwise?
I've personally never had a need to set the search_path to a system schema, and I guess I was implicitly modelling this on what is returned by \dn, not by \dnS. I wouldn't object much to including them; that would be better than not having any completion. I just don't see much point.
And now playing a bit with the system ones, I think it would be more confusing to offer them. pg_catalog and pg_temp_<appropriate> always get searched, whether you put them in the search_path or not.
Cheers,
Jeff
Re: Jeff Janes 2014-05-05 <CAMkU=1yo97bcGR-z6wg-OJpHKfEcaaaS=X1N7xYGxcUAKV5r9g@mail.gmail.com> > I've personally never had a need to set the search_path to a system schema, > and I guess I was implicitly modelling this on what is returned by \dn, not > by \dnS. I wouldn't object much to including them; that would be better > than not having any completion. I just don't see much point. > > And now playing a bit with the system ones, I think it would be more > confusing to offer them. pg_catalog and pg_temp_<appropriate> always get > searched, whether you put them in the search_path or not. Imho the system schemas should be included, because they don't hurt. If you do tab completion, you'll usually enter a few chars and hit <tab>, so you won't get confused by pg_catalog and information_schema just because you won't see them. Also, it makes sense to explicitely put pg_catalog at the beginning or the end of search_path, so tab completion should support that. I would opt to exclude pg_temp_*, though - these don't serve any purpose SQL-wise and the name changes all the time anyway. Christoph -- cb@df7cb.de | http://www.df7cb.de/
On 2014-05-05 09:10:17 -0700, Jeff Janes wrote: > On Sat, May 3, 2014 at 1:11 AM, Andres Freund <andres@2ndquadrant.com>wrote: > > > On 2014-05-03 00:13:45 -0700, Jeff Janes wrote: > > > On Friday, May 2, 2014, Jeff Janes <jeff.janes@gmail.com> wrote: > > Why should we exclude system schemata? That seems more likely to be > > confusing than helpful? I can see a point in excluding another backend's > > temp tables, but otherwise? > > > > I've personally never had a need to set the search_path to a system schema, > and I guess I was implicitly modelling this on what is returned by \dn, not > by \dnS. I wouldn't object much to including them; that would be better > than not having any completion. I just don't see much point. > > And now playing a bit with the system ones, I think it would be more > confusing to offer them. pg_catalog and pg_temp_<appropriate> always get > searched, whether you put them in the search_path or not. I thought about committing this but couldn't get over this bit. If you type "SELECT * FROM pg_cat<tab>" it'll get autocompleted to pg_catalog.pg_ and "pg_temp<tab>" will list all the temp schemas including the numeric and toast ones. So we have precedent for *not* bothering about excluding any schemas. I don't think we should start doing so in a piecemal fashion in an individual command's completion. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 23/06/14 00:58, Andres Freund wrote: > On 2014-05-05 09:10:17 -0700, Jeff Janes wrote: >> On Sat, May 3, 2014 at 1:11 AM, Andres Freund <andres@2ndquadrant.com>wrote: >> >>> On 2014-05-03 00:13:45 -0700, Jeff Janes wrote: >>>> On Friday, May 2, 2014, Jeff Janes <jeff.janes@gmail.com> wrote: >>> Why should we exclude system schemata? That seems more likely to be >>> confusing than helpful? I can see a point in excluding another backend's >>> temp tables, but otherwise? >>> >> >> I've personally never had a need to set the search_path to a system schema, >> and I guess I was implicitly modelling this on what is returned by \dn, not >> by \dnS. I wouldn't object much to including them; that would be better >> than not having any completion. I just don't see much point. >> >> And now playing a bit with the system ones, I think it would be more >> confusing to offer them. pg_catalog and pg_temp_<appropriate> always get >> searched, whether you put them in the search_path or not. > > I thought about committing this but couldn't get over this bit. If you > type "SELECT * FROM pg_cat<tab>" it'll get autocompleted to > pg_catalog.pg_ and "pg_temp<tab>" will list all the temp schemas > including the numeric and toast ones. So we have precedent for *not* > bothering about excluding any schemas. I don't think we should start > doing so in a piecemal fashion in an individual command's completion. There is an exception of sorts already for system schemas, in that although "SELECT * FROM p<tab>" will list the system schemas, it will not list any tables from them, and won't until "SELECT * FROM pg_<tab>" is entered (see note in tab-completion.c around line 3722). Personally I'd be mildly annoyed if every "SET search_path TO p<tab>" resulted in all the system schemas being displayed when all I want is "public"; how about having these listed only once "pg_" is entered, i.e. "SET search_path TO pg_<tab>"? Regards Ian Barwick -- Ian Barwick http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Ian Barwick <ian@2ndquadrant.com> writes:
> On 23/06/14 00:58, Andres Freund wrote:
>> I thought about committing this but couldn't get over this bit. If you
>> type "SELECT * FROM pg_cat<tab>" it'll get autocompleted to
>> pg_catalog.pg_ and "pg_temp<tab>" will list all the temp schemas
>> including the numeric and toast ones. So we have precedent for *not*
>> bothering about excluding any schemas. I don't think we should start
>> doing so in a piecemal fashion in an individual command's completion.
> There is an exception of sorts already for system schemas, in that although
> "SELECT * FROM p<tab>" will list the system schemas, it will not list any
> tables from them, and won't until "SELECT * FROM pg_<tab>" is entered
> (see note in tab-completion.c around line 3722).
> Personally I'd be mildly annoyed if every "SET search_path TO p<tab>" resulted
> in all the system schemas being displayed when all I want is "public"; how
> about having these listed only once "pg_" is entered, i.e.
> "SET search_path TO pg_<tab>"?
I think there is a pretty strong practical argument for excluding the
pg_temp and pg_toast schemas from completion for search_path, namely
that when does anyone ever need to include those in their search_path
explicitly?
The use-case for including pg_catalog in your path is perhaps a bit
greater, but not by much.
I'm not sure that what we do when auto-completing after FROM is an
entirely valid analogy, because the use-cases are different as a result
of the rules about schemas getting automatically included in your path.
regards, tom lane
On 2014-06-22 20:02:57 -0700, Tom Lane wrote: > Ian Barwick <ian@2ndquadrant.com> writes: > > On 23/06/14 00:58, Andres Freund wrote: > >> I thought about committing this but couldn't get over this bit. If you > >> type "SELECT * FROM pg_cat<tab>" it'll get autocompleted to > >> pg_catalog.pg_ and "pg_temp<tab>" will list all the temp schemas > >> including the numeric and toast ones. So we have precedent for *not* > >> bothering about excluding any schemas. I don't think we should start > >> doing so in a piecemal fashion in an individual command's completion. > > > There is an exception of sorts already for system schemas, in that although > > "SELECT * FROM p<tab>" will list the system schemas, it will not list any > > tables from them, and won't until "SELECT * FROM pg_<tab>" is entered > > (see note in tab-completion.c around line 3722). > > > Personally I'd be mildly annoyed if every "SET search_path TO p<tab>" resulted > > in all the system schemas being displayed when all I want is "public"; how > > about having these listed only once "pg_" is entered, i.e. > > "SET search_path TO pg_<tab>"? > > I think there is a pretty strong practical argument for excluding the > pg_temp and pg_toast schemas from completion for search_path, namely > that when does anyone ever need to include those in their search_path > explicitly? Infrequently, yes. I've only done it when trying to break stuff ;) > The use-case for including pg_catalog in your path is perhaps a bit > greater, but not by much. I don't know. It feelds like inappropriate nannyism to me. More confusing than actually helpful. The schemas are there, so they should get autocompleted. But anyway, the common opinion seems to be swinging against my position, so lets do it that way. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
Andres Freund <andres@2ndquadrant.com> wrote: > On 2014-06-22 20:02:57 -0700, Tom Lane wrote: >> Ian Barwick <ian@2ndquadrant.com> writes: >>> On 23/06/14 00:58, Andres Freund wrote: >>>> I thought about committing this but couldn't get over this bit. If you >>>> type "SELECT * FROM pg_cat<tab>" it'll get autocompleted to >>>> pg_catalog.pg_ and "pg_temp<tab>" will list all the temp schemas >>>> including the numeric and toast ones. So we have precedent for *not* >>>> bothering about excluding any schemas. I don't think we should start >>>> doing so in a piecemal fashion in an individual command's completion. >> >>> There is an exception of sorts already for system schemas, in that although >>> "SELECT * FROM p<tab>" will list the system schemas, it will not list any >>> tables from them, and won't until "SELECT * FROM pg_<tab>" is entered >>> (see note in tab-completion.c around line 3722). >> >>> Personally I'd be mildly annoyed if every "SET search_path TO p<tab>" resulted >>> in all the system schemas being displayed when all I want is "public"; how >>> about having these listed only once "pg_" is entered, i.e. >>> "SET search_path TO pg_<tab>"? >> >> I think there is a pretty strong practical argument for excluding the >> pg_temp and pg_toast schemas from completion for search_path, namely >> that when does anyone ever need to include those in their search_path >> explicitly? > > Infrequently, yes. I've only done it when trying to break stuff ;) > >> The use-case for including pg_catalog in your path is perhaps a bit >> greater, but not by much. > > I don't know. It feelds like inappropriate nannyism to me. More > confusing than actually helpful. The schemas are there, so they should > get autocompleted. > But anyway, the common opinion seems to be swinging against my position, > so lets do it that way. I would be for excluding the pg_toast, pg_toast_temp_n, and pg_temp_n schemas, and including public and pg_catalog. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Mon, Jun 23, 2014 at 9:10 AM, Kevin Grittner <kgrittn@ymail.com> wrote: > Andres Freund <andres@2ndquadrant.com> wrote: >> On 2014-06-22 20:02:57 -0700, Tom Lane wrote: >>> Ian Barwick <ian@2ndquadrant.com> writes: >>>> On 23/06/14 00:58, Andres Freund wrote: >>>>> I thought about committing this but couldn't get over this bit. If you >>>>> type "SELECT * FROM pg_cat<tab>" it'll get autocompleted to >>>>> pg_catalog.pg_ and "pg_temp<tab>" will list all the temp schemas >>>>> including the numeric and toast ones. So we have precedent for *not* >>>>> bothering about excluding any schemas. I don't think we should start >>>>> doing so in a piecemal fashion in an individual command's completion. >>> >>>> There is an exception of sorts already for system schemas, in that although >>>> "SELECT * FROM p<tab>" will list the system schemas, it will not list any >>>> tables from them, and won't until "SELECT * FROM pg_<tab>" is entered >>>> (see note in tab-completion.c around line 3722). >>> >>>> Personally I'd be mildly annoyed if every "SET search_path TO p<tab>" resulted >>>> in all the system schemas being displayed when all I want is "public"; how >>>> about having these listed only once "pg_" is entered, i.e. >>>> "SET search_path TO pg_<tab>"? >>> >>> I think there is a pretty strong practical argument for excluding the >>> pg_temp and pg_toast schemas from completion for search_path, namely >>> that when does anyone ever need to include those in their search_path >>> explicitly? >> >> Infrequently, yes. I've only done it when trying to break stuff ;) >> >>> The use-case for including pg_catalog in your path is perhaps a bit >>> greater, but not by much. >> >> I don't know. It feelds like inappropriate nannyism to me. More >> confusing than actually helpful. The schemas are there, so they should >> get autocompleted. >> But anyway, the common opinion seems to be swinging against my position, >> so lets do it that way. > > I would be for excluding the pg_toast, pg_toast_temp_n, and > pg_temp_n schemas, and including public and pg_catalog. +1. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 2014-06-23 13:10:34 -0400, Robert Haas wrote: > On Mon, Jun 23, 2014 at 9:10 AM, Kevin Grittner <kgrittn@ymail.com> wrote: > > I would be for excluding the pg_toast, pg_toast_temp_n, and > > pg_temp_n schemas, and including public and pg_catalog. > > +1. Jeff, are you willing to update the patch that way? Seems we have something several people can live with ;) Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Mon, Jun 23, 2014 at 3:53 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-06-23 13:10:34 -0400, Robert Haas wrote:
>> On Mon, Jun 23, 2014 at 9:10 AM, Kevin Grittner <kgrittn@ymail.com> wrote:
>> > I would be for excluding the pg_toast, pg_toast_temp_n, and
>> > pg_temp_n schemas, and including public and pg_catalog.
>>
>> +1.
>
> Jeff, are you willing to update the patch that way? Seems we have
> something several people can live with ;)
> On 2014-06-23 13:10:34 -0400, Robert Haas wrote:
>> On Mon, Jun 23, 2014 at 9:10 AM, Kevin Grittner <kgrittn@ymail.com> wrote:
>> > I would be for excluding the pg_toast, pg_toast_temp_n, and
>> > pg_temp_n schemas, and including public and pg_catalog.
>>
>> +1.
>
> Jeff, are you willing to update the patch that way? Seems we have
> something several people can live with ;)
I was hoping not to add a third set of filters (separate from the ones already implicit in either \dn or \dnS), but that's OK; as long as I get a doghouse I won't worry much about the color.
I've included information_schema as well, in analogy to the inclusion of pg_catalog.
Cheers and Thanks,
Jeff
On Mon, Jun 23, 2014 at 6:25 PM, Jeff Janes <jeff.janes@gmail.com> wrote: > On Mon, Jun 23, 2014 at 3:53 PM, Andres Freund <andres@2ndquadrant.com> > wrote: >> On 2014-06-23 13:10:34 -0400, Robert Haas wrote: >>> On Mon, Jun 23, 2014 at 9:10 AM, Kevin Grittner <kgrittn@ymail.com> >>> wrote: >>> > I would be for excluding the pg_toast, pg_toast_temp_n, and >>> > pg_temp_n schemas, and including public and pg_catalog. >>> >>> +1. >> >> Jeff, are you willing to update the patch that way? Seems we have >> something several people can live with ;) > > I was hoping not to add a third set of filters (separate from the ones > already implicit in either \dn or \dnS), but that's OK; as long as I get a > doghouse I won't worry much about the color. > > I've included information_schema as well, in analogy to the inclusion of > pg_catalog. > > Cheers and Thanks, GAAH. I specifically verified before hitting send that the attachment was listed. Nevertheless, it isn't there. Note to self: stop using gmail offline to compose mail with attachments to send later, it prevaricates. Attempted again with regular gmail this time. Cheers, Jeff
Attachment
On Tue, Jun 24, 2014 at 11:57 AM, Jeff Janes <jeff.janes@gmail.com> wrote: > On Mon, Jun 23, 2014 at 6:25 PM, Jeff Janes <jeff.janes@gmail.com> wrote: >> On Mon, Jun 23, 2014 at 3:53 PM, Andres Freund <andres@2ndquadrant.com> >> wrote: >>> On 2014-06-23 13:10:34 -0400, Robert Haas wrote: >>>> On Mon, Jun 23, 2014 at 9:10 AM, Kevin Grittner <kgrittn@ymail.com> >>>> wrote: >>>> > I would be for excluding the pg_toast, pg_toast_temp_n, and >>>> > pg_temp_n schemas, and including public and pg_catalog. >>>> >>>> +1. >>> >>> Jeff, are you willing to update the patch that way? Seems we have >>> something several people can live with ;) >> >> I was hoping not to add a third set of filters (separate from the ones >> already implicit in either \dn or \dnS), but that's OK; as long as I get a >> doghouse I won't worry much about the color. >> >> I've included information_schema as well, in analogy to the inclusion of >> pg_catalog. Is there any blocker on this patch? The patch looks good to me. Regards, -- Fujii Masao
On Mon, Jul 7, 2014 at 8:51 PM, Fujii Masao <masao.fujii@gmail.com> wrote: > On Tue, Jun 24, 2014 at 11:57 AM, Jeff Janes <jeff.janes@gmail.com> wrote: >> On Mon, Jun 23, 2014 at 6:25 PM, Jeff Janes <jeff.janes@gmail.com> wrote: >>> On Mon, Jun 23, 2014 at 3:53 PM, Andres Freund <andres@2ndquadrant.com> >>> wrote: >>>> On 2014-06-23 13:10:34 -0400, Robert Haas wrote: >>>>> On Mon, Jun 23, 2014 at 9:10 AM, Kevin Grittner <kgrittn@ymail.com> >>>>> wrote: >>>>> > I would be for excluding the pg_toast, pg_toast_temp_n, and >>>>> > pg_temp_n schemas, and including public and pg_catalog. >>>>> >>>>> +1. >>>> >>>> Jeff, are you willing to update the patch that way? Seems we have >>>> something several people can live with ;) >>> >>> I was hoping not to add a third set of filters (separate from the ones >>> already implicit in either \dn or \dnS), but that's OK; as long as I get a >>> doghouse I won't worry much about the color. >>> >>> I've included information_schema as well, in analogy to the inclusion of >>> pg_catalog. > > Is there any blocker on this patch? The patch looks good to me. The patch makes the tab-completion on search_path display the existing schemas, additionally what about displaying "$user", too? I think that some users would want to include "$user" variable in search_path. Regards, -- Fujii Masao
Hi,
On 2014-06-23 19:57:21 -0700, Jeff Janes wrote:
> diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
> new file mode 100644
> index be5c3c5..dcd1b7d
> *** a/src/bin/psql/tab-complete.c
> --- b/src/bin/psql/tab-complete.c
> *************** psql_completion(const char *text, int st
> *** 3342,3347 ****
> --- 3342,3354 ----
>
> COMPLETE_WITH_LIST(my_list);
> }
> + else if (pg_strcasecmp(prev2_wd, "search_path") == 0)
> + {
> + COMPLETE_WITH_QUERY(Query_for_list_of_schemas
> + " AND nspname not like 'pg\\_toast%%' "
> + " AND nspname not like 'pg\\_temp%%' "
> + " UNION SELECT 'DEFAULT' ");
> + }
> else
> {
> static const char *const my_list[] =
I don't particularly like the explicit comparisons using LIKE, but we
can't really do better as we only have pg_my_temp_schema(),
pg_is_other_temp_schema() right now. I was tempted to just add
pg_is_temp_schema() and pg_is_toast_schema(), but we couldn't rely on
them for now anyway due to cross version compatibility.
We really should add those functions independently of this though.
I'm also not really happy with the fact that we only complete a single
search_path item. But it's not easy to do better and when looking around
other places (e.g. DROP TABLE) don't support it either.
I've thought about adding "$user" to the set of completed things as
Fujii wondered about it, but it turns out completions containing $ don't
work really great because $ is part of WORD_BREAKS.
E.g. check out what happens if you do
CREATE TABLE "foo$01"();
CREATE TABLE "foo$02"();
DROP TABLE "foo$<tab>
which means that a single schema that requires quoting will break
completion of "$user".
Pushed.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
Re: Andres Freund 2014-07-12 <20140712135128.GD3494@awork2.anarazel.de> > I'm also not really happy with the fact that we only complete a single > search_path item. But it's not easy to do better and when looking around > other places (e.g. DROP TABLE) don't support it either. The difference is that the other places don't really need it, i.e. you can just issue two DROP TABLE. (And I wasn't even aware that DROP TABLE a, b; exists specifically). That said, it's great to have the feature, though I'd say making search_path list-aware should be much higher on the todo list than a generic solution for other cases. > I've thought about adding "$user" to the set of completed things as If we only support one item atm, $user isn't very relevant anyway. > Fujii wondered about it, but it turns out completions containing $ don't > work really great because $ is part of WORD_BREAKS. > E.g. check out what happens if you do > CREATE TABLE "foo$01"(); > CREATE TABLE "foo$02"(); > DROP TABLE "foo$<tab> > which means that a single schema that requires quoting will break > completion of "$user". Schemas requiring quoting should be rare, so that wouldn't be a big problem. (Or at least it could solve the problem for most users.) Christoph -- cb@df7cb.de | http://www.df7cb.de/