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
