Re: [BUGS] Tab completion of function arguments not working in all cases

From: Josh Kupershmidt <schmiddy(at)gmail(dot)com>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [BUGS] Tab completion of function arguments not working in all cases
Date: 2012-06-18 03:21:27
Message-ID: CAK3UJRGA5fmxw40SpN0p3EjXOgwSyP_T=XMz5pdbcLx6FSeRPQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

[Hope it's OK if I move this thread to -hackers, as part of CF review.]

On Sat, Jun 9, 2012 at 2:40 AM, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> Hi,
>
> I noticed this while testing 9.2, but it seems to go back to at least
> 8.3. Tab completion of function arguments doesn't work if the function
> is schema-qualified or double-quoted. So for example,
>
>  DROP FUNCTION my_function ( <TAB>
>
> completes the functions arguments, but
>
>  DROP FUNCTION my_schema.my_function ( <TAB>
>
> doesn't offer any completions, and nor does
>
>  DROP FUNCTION "my function" ( <TAB>

+1 for the idea. I find the existing behavior rather confusing,
particularly the fact that a schema-qualified function name will be
tab-completed, i.e. this works.

DROP FUNCTION my_schema.my<TAB>

but then, as your second example above shows, no completions are
subsequently offered for the function arguments.

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.

> The attached patch fixes these problems by introducing a new macro
> COMPLETE_WITH_ARG, similar to the existing COMPLETE_WITH_ATTR, which
> seems to be the nearest analogous code that covers all the edge cases.

Anyway, on to the review of the patch itself:

* Submission *

Patch applies cleanly to git head, and regression tests are not
expected for tab-completion enhancements.

* Features & Usability *

I've verified that tab-completing of the first argument to functions
for DROP FUNCTION and ALTER FUNCTION commands for the most part works
as expected. The one catch I noticed was that
Query_for_list_of_arguments wasn't restricting its results to
currently-visible functions, so with a default search_path, if you
have these two functions defined:

public.doppelganger(text)
my_schema.doppelganger(bytea)

and then try:

DROP FUNCTION doppelganger(<TAB>

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.

* Coding *

The new macro COMPLETE_WITH_ARG seems fine. The existing code used
malloc() directly for DROP FUNCTION and ALTER FUNCTION
(tab-complete.c, around lines 867 and 2190), which AIUI is frowned
upon in favor of pg_malloc(). The patch avoids this ugliness by using
the new COMPLETE_WITH_ARG macro, so that's a nice fixup.

Overall, a nice fix for an overlooked piece of the tab-completion machinery.

Josh

Attachment Content-Type Size
tab-complete.funcargs.v2.diff application/octet-stream 4.1 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Dean Rasheed 2012-06-18 10:56:53 Re: [BUGS] Tab completion of function arguments not working in all cases
Previous Message weixing.sun 2012-06-16 17:39:29 BUG #6696: 9.2beta2 crashed when having shared_buffers>20GB

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-06-18 03:35:49 Re: SQL standard changed behavior of ON UPDATE SET NULL/SET DEFAULT?
Previous Message Quan Zongliang 2012-06-18 01:44:26 Re: compare lower case and upper case when encoding is utf-8