On 23/06/14 00:58, Andres Freund wrote:
On 2014-05-05 09:10:17 -0700, Jeff Janes wrote:
On Sat, May 3, 2014 at 1:11 AM, Andres Freund <and...@2ndquadrant.com>wrote:
On 2014-05-03 00:13:45 -0700, Jeff Janes wrote:
On Friday, May 2, 2014, Jeff Janes <jeff.ja...@gmail.com> wrote:
Why should we exclude system schemata? That seems more likely to be
confusing than helpful? I can see a point in excluding another backend's
temp tables, but otherwise?
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.
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>"?
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
