Skip site navigation (1) Skip section navigation (2)

psql \i tab completion initialization problem on HEAD

From: Peter van Hardenberg <pvh(at)pvh(dot)ca>
To: "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: psql \i tab completion initialization problem on HEAD
Date: 2012-02-23 23:23:50
Message-ID: CAAcg=kXKsaOGtRtsG_eYsXZ-kYBCu61bdOATGazzW5CXQfdoeQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
While testing Noah's filename quoting patch on my local development
machine, I noticed some strange behaviour around tab completion with
\i; it doesn't appear to be present in 9.1, but it is present on 9.2
HEAD and appears to be present with and without readline.

It manifests as the client preferring statement completion over
filename completion until the first time \i is forced to check
something on disk, after which it begins to work as expected.

Here's a reliable reproduction on my OS X laptop.

-> % bin/psql
psql (9.2devel, server 9.0.4)
WARNING: psql version 9.2, server version 9.0.
         Some psql features might not work.
Type "help" for help.

pvh=# \i <TAB><TAB>
ABORT           ALTER           ANALYZE         BEGIN
CHECKPOINT      CLOSE           CLUSTER         COMMENT         COMMIT
         COPY            CREATE          DEALLOCATE
DECLARE         DELETE FROM     DISCARD         DO              DROP
         END             EXECUTE         EXPLAIN         FETCH
  GRANT           INSERT          LISTEN
LOAD            LOCK            MOVE            NOTIFY
PREPARE         REASSIGN        REINDEX         RELEASE         RESET
         REVOKE          ROLLBACK        SAVEPOINT
SECURITY LABEL  SELECT          SET             SHOW            START
         TABLE           TRUNCATE        UNLISTEN        UPDATE
  VACUUM          VALUES          WITH
pvh=# \i asdf
asdf: No such file or directory
pvh=# \i ./<TAB><TAB>
./bin      ./include  ./lib      ./oh hai   ./share
pvh=# \i

I don't see this regression with the 9.1 client I have here, so I
suspect it has something to do with whatever patch introduced the
relative paths by default.

-p

-- 
Peter van Hardenberg
San Francisco, California
"Everything was beautiful, and nothing hurt." -- Kurt Vonnegut

Responses

pgsql-hackers by date

Next:From: Noah MischDate: 2012-02-23 23:57:47
Subject: Re: foreign key locks, 2nd attempt
Previous:From: Peter EisentrautDate: 2012-02-23 23:16:30
Subject: Re: Notes about fixing regexes and UTF-8 (yet again)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group