Re: tab completion for setting search_path

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