Re: EXECUTE tab completion

Josh Kupershmidt <schmiddy@gmail.com>

From: Josh Kupershmidt <schmiddy@gmail.com>

To: Tom Lane <tgl@sss.pgh.pa.us>

Cc: Andreas Karlsson <andreas@proxel.se>, PostgreSQL-development <pgsql-hackers@postgresql.org>

Date: 2011-10-20T02:50:58Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Add ALTER TABLE ... ALTER COLUMN ... SET STATISTICS DISTINCT
- 907259294654 9.0.0 cited

On Wed, Oct 19, 2011 at 10:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Josh Kupershmidt <schmiddy@gmail.com> writes:
>> Incidentally, I was wondering what the heck was up with a clause like this:
>>     else if (pg_strcasecmp(prev_wd, "EXECUTE") == 0 &&
>>              pg_strcasecmp(prev2_wd, "EXECUTE") == 0)
>
> Hmm, maybe || was meant not && ?  It seems pretty unlikely that the
> above test would ever trigger on valid SQL input.

Well, changing '&&' to '||' breaks the stated comment of the patch, namely:
          /* must not match CREATE TRIGGER ... EXECUTE PROCEDURE */

I assume this is an accepted quirk of previous_word() since we have
this existing similar code:

/* DROP, but watch out for DROP embedded in other commands */
    /* complete with something you can drop */
    else if (pg_strcasecmp(prev_wd, "DROP") == 0 &&
             pg_strcasecmp(prev2_wd, "DROP") == 0)

and the patch does seem to auto-complete a beginning EXECUTE
correctly. We could probably use a comment somewhere explaining this
quirk.

Josh