Re: tab completion for setting search_path

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kevin Grittner <kgrittn(at)ymail(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ian Barwick <ian(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: tab completion for setting search_path
Date: 2014-06-23 17:10:34
Message-ID: CA+Tgmoa7gLfwNakgKDq0GT8WNPmHXpY-ccx6-2TVX27pxOkEdg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-06-23 17:21:22 Re: Use a signal to trigger a memory context dump?
Previous Message Andres Freund 2014-06-23 17:07:52 Re: Atomics hardware support table & supported architectures