Thread: psql tab completion for DO blocks
Folks, Please find enclosed a patch which adds tab completion for DO blocks. Thanks to Andrew Gierth and Stefan Kaltenbrunner for help putting it together :) Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Attachment
David Fetter <david@fetter.org> writes:
> Please find enclosed a patch which adds tab completion for DO blocks.
Seems (a) rather pointless and (b) wrong in detail.
regards, tom lane
On Sat, Jan 02, 2010 at 04:22:38PM -0500, Tom Lane wrote: > David Fetter <david@fetter.org> writes: > > Please find enclosed a patch which adds tab completion for DO > > blocks. > > Seems (a) rather pointless and I don't find it so. > (b) wrong in detail. How? That it can't look back past the code block is reflects limitations in lexx and yacc, a problem which, to put it mildly, is much larger than I can address in a single patch. It does produce correct results for front-loading the language in which the DO block is to be created. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter <david@fetter.org> writes:
> On Sat, Jan 02, 2010 at 04:22:38PM -0500, Tom Lane wrote:
>> (b) wrong in detail.
> How?
It doesn't actually work, because the query isn't paying attention to
the current partial word. Try do language pl<tab>, or just compare
source to the original Query_for_list_of_languages.
regards, tom lane
On Sat, Jan 02, 2010 at 04:53:45PM -0500, Tom Lane wrote: > David Fetter <david@fetter.org> writes: > > On Sat, Jan 02, 2010 at 04:22:38PM -0500, Tom Lane wrote: > >> (b) wrong in detail. > > > How? > > It doesn't actually work, because the query isn't paying attention to > the current partial word. Try do language pl<tab>, or just compare > source to the original Query_for_list_of_languages. Thanks for the heads-up. New patch attached :) Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Attachment
David Fetter <david@fetter.org> writes:
>> It doesn't actually work, because the query isn't paying attention to
>> the current partial word. Try do language pl<tab>, or just compare
>> source to the original Query_for_list_of_languages.
> Thanks for the heads-up. New patch attached :)
My inclination is to not have the separate query at all, but just
use Query_for_list_of_languages. The extra maintenance burden of
two almost identical queries is not justified here IMO. Maybe it
would be if we foresaw that most languages would remain without
inline handlers indefinitely, but I think that pretty soon the
only one that the query is actually excluding would be 'C', and
it's not worth trying to remove that from the list.
regards, tom lane
On Sat, Jan 02, 2010 at 05:10:08PM -0500, Tom Lane wrote: > David Fetter <david@fetter.org> writes: > >> It doesn't actually work, because the query isn't paying attention to > >> the current partial word. Try do language pl<tab>, or just compare > >> source to the original Query_for_list_of_languages. > > > Thanks for the heads-up. New patch attached :) > > My inclination is to not have the separate query at all, I made one so people couldn't tab complete themselves an unpleasant surprise. The overhead doesn't seem huge. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter <david@fetter.org> writes:
>> My inclination is to not have the separate query at all,
> I made one so people couldn't tab complete themselves an unpleasant
> surprise. The overhead doesn't seem huge.
What unpleasant surprise is that going to be? They'll get an error
message telling them there's no inline support. That seems to me to
be more user-friendly than forcing them to type out the language name
and then getting the same error message.
As for the overhead, these queries are not zero-maintenance. I still
think that the usefulness of tab completion here is pretty darn minimal,
since most people are more likely to rely on default_do_language;
so I don't see the point of carrying an extra query to tweak the
behavior in a way that isn't even obviously an improvement.
regards, tom lane
On lör, 2010-01-02 at 17:34 -0500, Tom Lane wrote: > As for the overhead, these queries are not zero-maintenance. I still > think that the usefulness of tab completion here is pretty darn > minimal, > since most people are more likely to rely on default_do_language; We really don't have any data on that, and it doesn't seem all that likely to me.
Peter Eisentraut <peter_e@gmx.net> writes:
> On lör, 2010-01-02 at 17:34 -0500, Tom Lane wrote:
>> As for the overhead, these queries are not zero-maintenance. I still
>> think that the usefulness of tab completion here is pretty darn
>> minimal,
>> since most people are more likely to rely on default_do_language;
> We really don't have any data on that, and it doesn't seem all that
> likely to me.
I'm not really objecting to putting in the patch entirely. I'm objecting
to carrying an extra completion query for it. I don't think hiding
languages with laninline=0 improves its usefulness at all, let alone
enough to justify extra maintenance burden.
regards, tom lane
On Sat, Jan 2, 2010 at 7:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> On lör, 2010-01-02 at 17:34 -0500, Tom Lane wrote: >>> As for the overhead, these queries are not zero-maintenance. I still >>> think that the usefulness of tab completion here is pretty darn >>> minimal, >>> since most people are more likely to rely on default_do_language; > >> We really don't have any data on that, and it doesn't seem all that >> likely to me. > > I'm not really objecting to putting in the patch entirely. I'm objecting > to carrying an extra completion query for it. I don't think hiding > languages with laninline=0 improves its usefulness at all, let alone > enough to justify extra maintenance burden. As a practical matter there aren't that many languages in the first place, and many of them begin with the same few letters. If you have both plperl and plpython loaded (and they both have inline handlers) you'll have to type four characters to disambiguate, and by that time (especially for plperl) you might as well just finish typing it by hand. Having said that, I don't see much value in deliberately making the tab-completion list fail to match the set of arguments that will actually work. The maintenance burden of an additional query strikes me as not worth worrying about. If David finds it useful and/or has users who want it, I think we should just do it. ...Robert
Robert Haas wrote: > On Sat, Jan 2, 2010 at 7:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Peter Eisentraut <peter_e@gmx.net> writes: > >> On l?r, 2010-01-02 at 17:34 -0500, Tom Lane wrote: > >>> As for the overhead, these queries are not zero-maintenance. ?I still > >>> think that the usefulness of tab completion here is pretty darn > >>> minimal, > >>> since most people are more likely to rely on default_do_language; > > > >> We really don't have any data on that, and it doesn't seem all that > >> likely to me. > > > > I'm not really objecting to putting in the patch entirely. ?I'm objecting > > to carrying an extra completion query for it. ?I don't think hiding > > languages with laninline=0 improves its usefulness at all, let alone > > enough to justify extra maintenance burden. > > As a practical matter there aren't that many languages in the first > place, and many of them begin with the same few letters. If you have > both plperl and plpython loaded (and they both have inline handlers) > you'll have to type four characters to disambiguate, and by that time > (especially for plperl) you might as well just finish typing it by > hand. > > Having said that, I don't see much value in deliberately making the > tab-completion list fail to match the set of arguments that will > actually work. The maintenance burden of an additional query strikes > me as not worth worrying about. If David finds it useful and/or has > users who want it, I think we should just do it. Where are we on this patch? We should at least implement the completion for 'LANGUAGE' in 'DO', and use the existing pg_language query for completion. I am attaching a patch that does exactly this. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: src/bin/psql/tab-complete.c =================================================================== RCS file: /cvsroot/pgsql/src/bin/psql/tab-complete.c,v retrieving revision 1.192 diff -c -c -r1.192 tab-complete.c *** src/bin/psql/tab-complete.c 25 Jan 2010 18:23:09 -0000 1.192 --- src/bin/psql/tab-complete.c 6 Feb 2010 19:09:26 -0000 *************** *** 618,624 **** static const char *const sql_commands[] = { "ABORT", "ALTER", "ANALYZE", "BEGIN", "CHECKPOINT", "CLOSE", "CLUSTER", "COMMENT", "COMMIT", "COPY", "CREATE", "DEALLOCATE", "DECLARE", ! "DELETE FROM", "DISCARD", "DROP", "END", "EXECUTE", "EXPLAIN", "FETCH", "GRANT", "INSERT", "LISTEN", "LOAD", "LOCK", "MOVE", "NOTIFY", "PREPARE", "REASSIGN", "REINDEX", "RELEASE", "RESET", "REVOKE", "ROLLBACK", "SAVEPOINT", "SELECT", "SET", "SHOW", "START", "TABLE", "TRUNCATE", "UNLISTEN", --- 618,624 ---- static const char *const sql_commands[] = { "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", "SELECT", "SET", "SHOW", "START", "TABLE", "TRUNCATE", "UNLISTEN", *************** *** 1532,1537 **** --- 1532,1555 ---- COMPLETE_WITH_LIST(list_DISCARD); } + /* DO */ + /* + * Complete DO with LANGUAGE. + */ + else if (pg_strcasecmp(prev_wd, "DO") == 0) + { + static const char *const list_DO[] = + {"LANGUAGE", NULL}; + + COMPLETE_WITH_LIST(list_DO); + } + /* + * Complete DO LANGUAGE with in-line-able languages. + */ + else if (pg_strcasecmp(prev2_wd, "DO") == 0 && + pg_strcasecmp(prev_wd, "LANGUAGE") == 0) + COMPLETE_WITH_QUERY(Query_for_list_of_languages); + /* DROP (when not the previous word) */ /* DROP AGGREGATE */ else if (pg_strcasecmp(prev3_wd, "DROP") == 0 &&
Bruce Momjian <bruce@momjian.us> wrote: > Where are we on this patch? We should at least implement the completion > for 'LANGUAGE' in 'DO', and use the existing pg_language query for > completion. I am attaching a patch that does exactly this. I don't think we need the patch except adding DO to the top-level sql_commands. Syntax of DO command is: DO code [ LANGUAGE lang_name ] We need 'code' before LANGUAGE, but the patch completes "DO" to "DO LANGUAGE". It will be just a syntax error. Also, we've already had a completion after LANGUAGE (see words_after_create), so we don't need an additional Query_for_list_of_languages after LANGUAGE. BTW, I'm working on psql tab-completion adjustment for new syntax in 9.0. I'll send it soon. Regards, --- Takahiro Itagaki NTT Open Source Software Center
Takahiro Itagaki wrote: > > Bruce Momjian <bruce@momjian.us> wrote: > > > Where are we on this patch? We should at least implement the completion > > for 'LANGUAGE' in 'DO', and use the existing pg_language query for > > completion. I am attaching a patch that does exactly this. > > I don't think we need the patch except adding DO to the top-level sql_commands. > > Syntax of DO command is: > DO code [ LANGUAGE lang_name ] > We need 'code' before LANGUAGE, but the patch completes "DO" to "DO LANGUAGE". > It will be just a syntax error. > > Also, we've already had a completion after LANGUAGE (see words_after_create), > so we don't need an additional Query_for_list_of_languages after LANGUAGE. Ah, I see. I had not checked the patch against the actual syntax; shame on me. > BTW, I'm working on psql tab-completion adjustment for new syntax in 9.0. > I'll send it soon. OK, thanks. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Wed, Feb 10, 2010 at 11:00:00AM +0900, Takahiro Itagaki wrote:
> Bruce Momjian <bruce@momjian.us> wrote:
>
> > Where are we on this patch? We should at least implement the completion
> > for 'LANGUAGE' in 'DO', and use the existing pg_language query for
> > completion. I am attaching a patch that does exactly this.
>
> I don't think we need the patch except adding DO to the top-level sql_commands.
>
> Syntax of DO command is:
> DO code [ LANGUAGE lang_name ]
That's not the only syntax.
DO [LANGUAGE lang_name] code
also works, e.g.:
CREATE LANGUAGE plperl;
CREATE TABLE foo(id SERIAL PRIMARY KEY, t TEXT);
DO LANGUAGE plperl $$spi_exec_query(q[INSERT INTO foo(t) VALUES('aaa')]);$$;
SELECT * FROM foo;
The DO LANGUAGE lang_name code syntax is much clearer, as far as I'm
concerned, than putting the code block before the language anyhow. :)
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter <david@fetter.org> wrote: > > Syntax of DO command is: > > DO code [ LANGUAGE lang_name ] > > That's not the only syntax. > DO [LANGUAGE lang_name] code > also works, e.g.: Hmmm, but we mention only above syntax in the documentation. http://developer.postgresql.org/pgdocs/postgres/sql-do.html Should we fix the documentation when we add the tab completion? Regards, --- Takahiro Itagaki NTT Open Source Software Center
Takahiro Itagaki escreveu: > Should we fix the documentation when we add the tab completion? > Yes, it seems consistent with other commands having optional parameters in the middle of the command rather than at the end. -- Euler Taveira de Oliveira http://www.timbira.com/
On Fri, Feb 12, 2010 at 09:24:55AM +0900, Takahiro Itagaki wrote: > > David Fetter <david@fetter.org> wrote: > > > > Syntax of DO command is: > > > DO code [ LANGUAGE lang_name ] > > > > That's not the only syntax. > > DO [LANGUAGE lang_name] code > > also works, e.g.: > > Hmmm, but we mention only above syntax in the documentation. > http://developer.postgresql.org/pgdocs/postgres/sql-do.html > > Should we fix the documentation when we add the tab completion? Yes :) Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On Thu, Feb 11, 2010 at 11:26:10PM -0200, Euler Taveira de Oliveira wrote: > Takahiro Itagaki escreveu: > > Should we fix the documentation when we add the tab completion? > > > Yes, it seems consistent with other commands having optional > parameters in the middle of the command rather than at the end. It's consistent with how we do CREATE FUNCTION, where the order of parameters after RETURNS is arbitrary. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter escreveu:
> It's consistent with how we do CREATE FUNCTION, where the order of
> parameters after RETURNS is arbitrary.
>
If it is arbitrary the synopsis is wrong because it is imposing that code
should be written after DO. It should be:
DO { [ LANGUAGE lang_name ] | code } ...
-- Euler Taveira de Oliveira http://www.timbira.com/
On Fri, Feb 12, 2010 at 12:21:02AM -0200, Euler Taveira de Oliveira wrote:
> David Fetter escreveu:
> > It's consistent with how we do CREATE FUNCTION, where the order of
> > parameters after RETURNS is arbitrary.
> >
> If it is arbitrary the synopsis is wrong because it is imposing that
> code should be written after DO. It should be:
>
> DO { [ LANGUAGE lang_name ] | code } ...
Good catch :)
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter <david@fetter.org> wrote:
> > DO { [ LANGUAGE lang_name ] | code } ...
> Good catch :)
The tab completion patch and documentation fix were committed.
Thanks.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center