Re: tab completion for setting search_path

From: Christoph Berg <cb(at)df7cb(dot)de>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: tab completion for setting search_path
Date: 2014-05-06 13:46:49
Message-ID: 20140506134649.GD10014@msgid.df7cb.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-05-06 13:49:04 Re: sb_alloc: a new memory allocator for PostgreSQL
Previous Message Andres Freund 2014-05-06 13:44:59 Re: New pg_lsn type doesn't have hash/btree opclasses