Re: psql \i tab completion initialization problem on HEAD

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

Peter van Hardenberg <pvh(at)pvh(dot)ca> writes:
> 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.

Hm, I don't see that here. I get filename completion immediately.

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

OS X? Are you using GNU readline, or Apple's libedit?

regards, tom lane

On Thu, Feb 23, 2012 at 4:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Here's a reliable reproduction on my OS X laptop.
>
> OS X?  Are you using GNU readline, or Apple's libedit?
>

I reproduced it with both, but if that news is surprising to you, I
can certainly re-test.

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

Peter van Hardenberg <pvh(at)pvh(dot)ca> writes:
> On Thu, Feb 23, 2012 at 4:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Here's a reliable reproduction on my OS X laptop.

>> OS X? Are you using GNU readline, or Apple's libedit?

> I reproduced it with both, but if that news is surprising to you, I
> can certainly re-test.

Actually, what I should have asked is "are you running Lion?".
Because with libedit on Lion, tab completion is 100% broken, as per
http://archives.postgresql.org/pgsql-hackers/2011-07/msg01642.php
This is just the latest installment in a long and sad story of
libedit being mostly not up to snuff on OS X.

I can reproduce the behavior you mention on my own Mac, but the fact
that it appears to work after the first time is probably just blind
luck from happenstance locations of malloc results :-(

As for GNU readline, I suspect you weren't actually testing it.
Note that the thing called /usr/lib/libreadline.dylib is not GNU
readline, it's only a symlink to libedit.

regards, tom lane

On Fri, Feb 24, 2012 at 9:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Actually, what I should have asked is "are you running Lion?".
> Because with libedit on Lion, tab completion is 100% broken, as per
> http://archives.postgresql.org/pgsql-hackers/2011-07/msg01642.php
> This is just the latest installment in a long and sad story of
> libedit being mostly not up to snuff on OS X.
>
> I can reproduce the behavior you mention on my own Mac, but the fact
> that it appears to work after the first time is probably just blind
> luck from happenstance locations of malloc results :-(
>
> As for GNU readline, I suspect you weren't actually testing it.
> Note that the thing called /usr/lib/libreadline.dylib is not GNU
> readline, it's only a symlink to libedit.
>

I am indeed running Lion. Thanks for helping me track down the cause.

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