On Mon, Jun 23, 2014 at 9:10 AM, Kevin Grittner <kgri...@ymail.com> wrote: > Andres Freund <and...@2ndquadrant.com> wrote: >> On 2014-06-22 20:02:57 -0700, Tom Lane wrote: >>> Ian Barwick <i...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
