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/
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 |