Re: tab completion for setting search_path

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: tab completion for setting search_path
Дата
Msg-id 20140623112226.GP16260@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: tab completion for setting search_path  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: tab completion for setting search_path
Список pgsql-hackers
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.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: [Fwd: Re: proposal: new long psql parameter --on-error-stop]
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: idle_in_transaction_timeout