Re: psql tab completion for DO blocks

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. +