Re: 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(dot)janes(at)gmail(dot)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

On 2014-05-03 00:13:45 -0700, Jeff Janes wrote:
> On Friday, May 2, 2014, Jeff Janes <jeff(dot)janes(at)gmail(dot)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(at)2ndquadrant(dot)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(at)2ndquadrant(dot)com>wrote:

> On 2014-05-03 00:13:45 -0700, Jeff Janes wrote:
> > On Friday, May 2, 2014, Jeff Janes <jeff(dot)janes(at)gmail(dot)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?
>

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(at)mail(dot)gmail(dot)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(at)df7cb(dot)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(at)2ndquadrant(dot)com>wrote:
>
> > On 2014-05-03 00:13:45 -0700, Jeff Janes wrote:
> > > On Friday, May 2, 2014, Jeff Janes <jeff(dot)janes(at)gmail(dot)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(at)2ndquadrant(dot)com>wrote:
>>
>>> On 2014-05-03 00:13:45 -0700, Jeff Janes wrote:
>>>> On Friday, May 2, 2014, Jeff Janes <jeff(dot)janes(at)gmail(dot)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(at)2ndquadrant(dot)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(at)2ndquadrant(dot)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(at)2ndquadrant(dot)com> wrote:
> On 2014-06-22 20:02:57 -0700, Tom Lane wrote:
>> Ian Barwick <ian(at)2ndquadrant(dot)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(at)ymail(dot)com> wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> On 2014-06-22 20:02:57 -0700, Tom Lane wrote:
>>> Ian Barwick <ian(at)2ndquadrant(dot)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(at)ymail(dot)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(at)2ndquadrant(dot)com
<javascript:;>> wrote:
> On 2014-06-23 13:10:34 -0400, Robert Haas wrote:
>> On Mon, Jun 23, 2014 at 9:10 AM, Kevin Grittner <kgrittn(at)ymail(dot)com
<javascript:;>> 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(dot)janes(at)gmail(dot)com> wrote:
> On Mon, Jun 23, 2014 at 3:53 PM, Andres Freund <andres(at)2ndquadrant(dot)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(at)ymail(dot)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

On Tue, Jun 24, 2014 at 11:57 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> On Mon, Jun 23, 2014 at 6:25 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> On Mon, Jun 23, 2014 at 3:53 PM, Andres Freund <andres(at)2ndquadrant(dot)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(at)ymail(dot)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(dot)fujii(at)gmail(dot)com> wrote:
> On Tue, Jun 24, 2014 at 11:57 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> On Mon, Jun 23, 2014 at 6:25 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>>> On Mon, Jun 23, 2014 at 3:53 PM, Andres Freund <andres(at)2ndquadrant(dot)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(at)ymail(dot)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(dot)GD3494(at)awork2(dot)anarazel(dot)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(at)df7cb(dot)de | http://www.df7cb.de/