On Mon, Jun 18, 2012 at 3:56 AM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> On 18 June 2012 04:21, Josh Kupershmidt <schmiddy@gmail.com> wrote:
>> As a side note unrelated to this patch, I also dislike how function
>> name tab-completions will not fill in the opening parenthesis, which
>> makes for unnecessary work for the user, as one then has to type the
>> parenthesis and hit tab again to get possible completions for the
>> function arguments. The current behavior causes:
>> DROP FUNCTION my_f<TAB>
>>
>> which completes to:
>> DROP FUNCTION my_function
>>
>> enter parenthesis, and hit tab:
>> DROP FUNCTION my_function(<TAB>
>>
>> which, if there is only one match, could complete to:
>> DROP FUNCTION my_function(integer)
>>
>> when the last three steps could have been consolidated with better
>> tab-completion. Perhaps this could be a TODO.
>>
>
> Hmm, I find that it does automatically fill in the opening
> parenthesis, but only once there is a space after the completed
> function name. So
> "DROP FUNCTION my_f<TAB>" completes to "DROP FUNCTION my_function "
> (note the space at the end). Then pressing <TAB> one more time gives
> "DROP FUNCTION my_function ( ", and then pressing <TAB> again gives
> the function arguments.
>
> Alternatively "DROP FUNCTION my_function<TAB>" (no space after
> function name) first completes to "DROP FUNCTION my_function " (adding
> the space), and then completes with the opening parenthesis, and then
> with the function arguments.
>
> It's a bit clunky, but I find that repeatedly pressing <TAB> is easier
> than typing the opening bracket.
Interesting, I see the behavior you describe on Linux, using psql +
libreadline, and the behavior I showed (i.e. repeatedly pressing tab
won't automatically fill in the function arguments after the function
name is completed, seemingly because no space is deposited after the
completed function name) is with OS X 10.6, using psql + libedit.
[snip]
>> you get tab-completions for both "text)" and "bytea(", when you
>> probably expected only the former. That's easy to fix though, please
>> see attached v2 patch.
>
> Good catch.
> I think that's a useful additional test, and is also consistent with
> the existing code in Query_for_list_of_attributes.
OK, I'll mark Ready for Committer in the CF.
Josh