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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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