Thread: Uppercase tab completion keywords in psql?

Uppercase tab completion keywords in psql?

From
Bruce Momjian
Date:
Postgres 9.2 has been modified so psql no longer uppercases SQL keywords
when using tab completation, by this commit:
commit 69f4f1c3576abc535871c6cfa95539e32a36120fAuthor: Peter Eisentraut <peter_e@gmx.net>Date:   Wed Feb 1 20:16:40
2012+0200    psql: Case preserving completion of SQL key words    Instead of always completing SQL key words in upper
case,look at     the word being completed and match the case.    reviewed by Fujii Masao
 

For example, in 9.1:
test=> sel<TAB>

becomes
test=> SELECT

However, in 9.2, this will produce:
test=> select

FYI, fortunately this will still complete as upper case:
test=> Sel<TAB>

Robert Haas and I are disappointed by this change.  I liked the fact
that I could post nice-looking SQL queries without having to use my
capslock key (which I use as a second control key).  Any chance of
reverting this change?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


Re: Uppercase tab completion keywords in psql?

From
Andres Freund
Date:
On Thursday, March 22, 2012 10:49:55 PM Bruce Momjian wrote:
> Postgres 9.2 has been modified so psql no longer uppercases SQL keywords
> when using tab completation, by this commit:
> 
>     commit 69f4f1c3576abc535871c6cfa95539e32a36120f
>     Author: Peter Eisentraut <peter_e@gmx.net>
>     Date:   Wed Feb 1 20:16:40 2012 +0200
> 
>         psql: Case preserving completion of SQL key words

> Robert Haas and I are disappointed by this change.  I liked the fact
> that I could post nice-looking SQL queries without having to use my
> capslock key (which I use as a second control key).  Any chance of
> reverting this change?
Seconded.

Andres


Re: Uppercase tab completion keywords in psql?

From
Andrew Dunstan
Date:

On 03/22/2012 05:49 PM, Bruce Momjian wrote:
>
> Robert Haas and I are disappointed by this change.  I liked the fact
> that I could post nice-looking SQL queries without having to use my
> capslock key (which I use as a second control key).  Any chance of
> reverting this change?
>

Should it be governed by a setting?

cheers

andrew


Re: Uppercase tab completion keywords in psql?

From
Alvaro Herrera
Date:
Excerpts from Andrew Dunstan's message of jue mar 22 19:05:30 -0300 2012:
>
> On 03/22/2012 05:49 PM, Bruce Momjian wrote:
> >
> > Robert Haas and I are disappointed by this change.  I liked the fact
> > that I could post nice-looking SQL queries without having to use my
> > capslock key (which I use as a second control key).  Any chance of
> > reverting this change?
> >
>
> Should it be governed by a setting?

A \set variable perhaps?  +1  Would the old behavior be the default?

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


Re: Uppercase tab completion keywords in psql?

From
David Fetter
Date:
On Thu, Mar 22, 2012 at 06:05:30PM -0400, Andrew Dunstan wrote:
> On 03/22/2012 05:49 PM, Bruce Momjian wrote:
> >Robert Haas and I are disappointed by this change.  I liked the
> >fact that I could post nice-looking SQL queries without having to
> >use my capslock key (which I use as a second control key).  Any
> >chance of reverting this change?
> >
> 
> Should it be governed by a setting?

Something like (upper|lower|preserve) ?

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


Re: Uppercase tab completion keywords in psql?

From
David Fetter
Date:
On Fri, Mar 23, 2012 at 11:51:16AM -0300, Alvaro Herrera wrote:
> 
> Excerpts from Andrew Dunstan's message of jue mar 22 19:05:30 -0300 2012:
> > 
> > On 03/22/2012 05:49 PM, Bruce Momjian wrote:
> > >
> > > Robert Haas and I are disappointed by this change.  I liked the
> > > fact that I could post nice-looking SQL queries without having
> > > to use my capslock key (which I use as a second control key).
> > > Any chance of reverting this change?
> > >
> > 
> > Should it be governed by a setting?
> 
> A \set variable perhaps?  +1  Would the old behavior be the default?

+1 for defaulting to the old behavior.

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


Re: Uppercase tab completion keywords in psql?

From
Peter Geoghegan
Date:
On 22 March 2012 22:05, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> On 03/22/2012 05:49 PM, Bruce Momjian wrote:
>>
>>
>> Robert Haas and I are disappointed by this change.  I liked the fact
>> that I could post nice-looking SQL queries without having to use my
>> capslock key (which I use as a second control key).  Any chance of
>> reverting this change?
>>
>
> Should it be governed by a setting?

Perhaps, but I find the behaviour that was introduced by Peter's patch
to be a more preferable default.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services


Re: Uppercase tab completion keywords in psql?

From
Andrew Dunstan
Date:

On 03/23/2012 11:07 AM, Peter Geoghegan wrote:
> On 22 March 2012 22:05, Andrew Dunstan<andrew@dunslane.net>  wrote:
>>
>> On 03/22/2012 05:49 PM, Bruce Momjian wrote:
>>>
>>> Robert Haas and I are disappointed by this change.  I liked the fact
>>> that I could post nice-looking SQL queries without having to use my
>>> capslock key (which I use as a second control key).  Any chance of
>>> reverting this change?
>>>
>> Should it be governed by a setting?
> Perhaps, but I find the behaviour that was introduced by Peter's patch
> to be a more preferable default.


Upper casing SQL keywords is a common style, which is used in lots of 
our code (e.g. regression tests, psql queries, pg_dump). I think the 
default should match what is in effect our house style, and what we have 
historically done.

cheers

andrew




Re: Uppercase tab completion keywords in psql?

From
Tom Lane
Date:
Peter Geoghegan <peter@2ndquadrant.com> writes:
> On 22 March 2012 22:05, Andrew Dunstan <andrew@dunslane.net> wrote:
>> Should it be governed by a setting?

> Perhaps, but I find the behaviour that was introduced by Peter's patch
> to be a more preferable default.

FWIW, I like the new behavior better too.  I'm not particularly a
fan of all-caps.
        regards, tom lane


Re: Uppercase tab completion keywords in psql?

From
Peter Geoghegan
Date:
On 23 March 2012 15:13, Andrew Dunstan <andrew@dunslane.net> wrote:
> Upper casing SQL keywords is a common style, which is used in lots of our
> code (e.g. regression tests, psql queries, pg_dump). I think the default
> should match what is in effect our house style, and what we have
> historically done.

The code doesn't give preferential treatment to lower-case code - it
merely puts it on an even footing. I would agree with your position if
the change assumed that the user always wanted to use lower-case SQL,
but it does not. Rather, it intelligently infers what the user wants.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services


Re: Uppercase tab completion keywords in psql?

From
Peter Eisentraut
Date:
On fre, 2012-03-23 at 07:52 -0700, David Fetter wrote:
> On Thu, Mar 22, 2012 at 06:05:30PM -0400, Andrew Dunstan wrote:
> > On 03/22/2012 05:49 PM, Bruce Momjian wrote:
> > >Robert Haas and I are disappointed by this change.  I liked the
> > >fact that I could post nice-looking SQL queries without having to
> > >use my capslock key (which I use as a second control key).  Any
> > >chance of reverting this change?
> > >
> >
> > Should it be governed by a setting?
>
> Something like (upper|lower|preserve) ?

How about this patch then?  (There are actually four possible settings,
see patch.)


Attachment

Re: Uppercase tab completion keywords in psql?

From
Bruce Momjian
Date:
On Fri, Mar 30, 2012 at 08:16:59PM +0300, Peter Eisentraut wrote:
> On fre, 2012-03-23 at 07:52 -0700, David Fetter wrote:
> > On Thu, Mar 22, 2012 at 06:05:30PM -0400, Andrew Dunstan wrote:
> > > On 03/22/2012 05:49 PM, Bruce Momjian wrote:
> > > >Robert Haas and I are disappointed by this change.  I liked the
> > > >fact that I could post nice-looking SQL queries without having to
> > > >use my capslock key (which I use as a second control key).  Any
> > > >chance of reverting this change?
> > > >
> > > 
> > > Should it be governed by a setting?
> > 
> > Something like (upper|lower|preserve) ?
> 
> How about this patch then?  (There are actually four possible settings,
> see patch.)
> 

Yes, very nice.  I found the "preserve" modes confusing, but I see the
problem that saying "preserve" doesn't tell us how to expand a word
where we didn't type anything.

> +        Determines which letter case to use when completing an SQL key word.
> +        If set to <literal>lower</literal> or <literal>upper</literal>, the
> +        completed word will be in lower or upper case, respectively.  If set
> +        to <literal>preserve-lower</literal>
> +        or <literal>preserve-upper</literal> (the default), the completed word
> +        will be in the case of the word already entered, but words being
                       -----
 
The "being" word above got me confused;  I would remove it.

> +        completed without anything entered will be in lower or upper case,
> +        respectively.

"without anything" -> "with nothing" ?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


Re: Uppercase tab completion keywords in psql?

From
Bruce Momjian
Date:
Peter, where are we on this?

---------------------------------------------------------------------------

On Fri, Mar 30, 2012 at 08:16:59PM +0300, Peter Eisentraut wrote:
> On fre, 2012-03-23 at 07:52 -0700, David Fetter wrote:
> > On Thu, Mar 22, 2012 at 06:05:30PM -0400, Andrew Dunstan wrote:
> > > On 03/22/2012 05:49 PM, Bruce Momjian wrote:
> > > >Robert Haas and I are disappointed by this change.  I liked the
> > > >fact that I could post nice-looking SQL queries without having to
> > > >use my capslock key (which I use as a second control key).  Any
> > > >chance of reverting this change?
> > > >
> > > 
> > > Should it be governed by a setting?
> > 
> > Something like (upper|lower|preserve) ?
> 
> How about this patch then?  (There are actually four possible settings,
> see patch.)
> 

> diff --git i/doc/src/sgml/ref/psql-ref.sgml w/doc/src/sgml/ref/psql-ref.sgml
> index b849101..be9d37d 100644
> --- i/doc/src/sgml/ref/psql-ref.sgml
> +++ w/doc/src/sgml/ref/psql-ref.sgml
> @@ -2652,6 +2652,22 @@ bar
>        </varlistentry>
>  
>        <varlistentry>
> +        <term><varname>COMP_KEYWORD_CASE</varname></term>
> +        <listitem>
> +        <para>
> +        Determines which letter case to use when completing an SQL key word.
> +        If set to <literal>lower</literal> or <literal>upper</literal>, the
> +        completed word will be in lower or upper case, respectively.  If set
> +        to <literal>preserve-lower</literal>
> +        or <literal>preserve-upper</literal> (the default), the completed word
> +        will be in the case of the word already entered, but words being
> +        completed without anything entered will be in lower or upper case,
> +        respectively.
> +        </para>
> +        </listitem>
> +      </varlistentry>
> +
> +      <varlistentry>
>          <term><varname>DBNAME</varname></term>
>          <listitem>
>          <para>
> diff --git i/src/bin/psql/tab-complete.c w/src/bin/psql/tab-complete.c
> index 6f481bb..00d87d5 100644
> --- i/src/bin/psql/tab-complete.c
> +++ w/src/bin/psql/tab-complete.c
> @@ -682,7 +682,7 @@ static char **complete_from_variables(char *text,
>                          const char *prefix, const char *suffix);
>  static char *complete_from_files(const char *text, int state);
>  
> -static char *pg_strdup_same_case(const char *s, const char *ref);
> +static char *pg_strdup_keyword_case(const char *s, const char *ref);
>  static PGresult *exec_query(const char *query);
>  
>  static void get_previous_words(int point, char **previous_words, int nwords);
> @@ -3048,7 +3048,7 @@ create_or_drop_command_generator(const char *text, int state, bits32 excluded)
>      {
>          if ((pg_strncasecmp(name, text, string_length) == 0) &&
>              !(words_after_create[list_index - 1].flags & excluded))
> -            return pg_strdup_same_case(name, text);
> +            return pg_strdup_keyword_case(name, text);
>      }
>      /* if nothing matches, return NULL */
>      return NULL;
> @@ -3335,9 +3335,9 @@ complete_from_list(const char *text, int state)
>              if (completion_case_sensitive)
>                  return pg_strdup(item);
>              else
> -                /* If case insensitive matching was requested initially, return
> -                 * it in the case of what was already entered. */
> -                return pg_strdup_same_case(item, text);
> +                /* If case insensitive matching was requested initially, adjust
> +                 * the case according to setting. */
> +                return pg_strdup_keyword_case(item, text);
>          }
>      }
>  
> @@ -3374,9 +3374,9 @@ complete_from_const(const char *text, int state)
>          if (completion_case_sensitive)
>              return pg_strdup(completion_charp);
>          else
> -            /* If case insensitive matching was requested initially, return it
> -             * in the case of what was already entered. */
> -            return pg_strdup_same_case(completion_charp, text);
> +            /* If case insensitive matching was requested initially, adjust the
> +             * case according to setting. */
> +            return pg_strdup_keyword_case(completion_charp, text);
>      }
>      else
>          return NULL;
> @@ -3484,27 +3484,48 @@ complete_from_files(const char *text, int state)
>  
>  
>  /*
> - * Make a pg_strdup copy of s and convert it to the same case as ref.
> + * Make a pg_strdup copy of s and convert the case according to
> + * COMP_KEYWORD_CASE variable, using ref as the text that was already entered.
>   */
>  static char *
> -pg_strdup_same_case(const char *s, const char *ref)
> +pg_strdup_keyword_case(const char *s, const char *ref)
>  {
>      char *ret, *p;
>      unsigned char first = ref[0];
> +    int        tocase;
> +    const char *varval;
> +
> +    varval = GetVariable(pset.vars, "COMP_KEYWORD_CASE");
> +    if (!varval)
> +        tocase = 0;
> +    else if (strcmp(varval, "lower") == 0)
> +        tocase = -2;
> +    else if (strcmp(varval, "preserve-lower") == 0)
> +        tocase = -1;
> +    else if (strcmp(varval, "preserve-upper") == 0)
> +        tocase = +1;
> +    else if (strcmp(varval, "upper") == 0)
> +        tocase = +2;
> +    else
> +        tocase = 0;
>  
> -    if (isalpha(first))
> -    {
> -        ret = pg_strdup(s);
> -        if (islower(first))
> -            for (p = ret; *p; p++)
> -                *p = pg_tolower((unsigned char) *p);
> -        else
> -            for (p = ret; *p; p++)
> -                *p = pg_toupper((unsigned char) *p);
> -        return ret;
> -    }
> +    /* default */
> +    if (tocase == 0)
> +        tocase = +1;
> +
> +    ret = pg_strdup(s);
> +
> +    if (tocase == -2
> +        || ((tocase == -1 || tocase == +1) && islower(first))
> +        || (tocase == -1 && !isalpha(first))
> +        )
> +        for (p = ret; *p; p++)
> +            *p = pg_tolower((unsigned char) *p);
>      else
> -        return pg_strdup(s);
> +        for (p = ret; *p; p++)
> +            *p = pg_toupper((unsigned char) *p);
> +
> +    return ret;
>  }
>  
>  


--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


Re: Uppercase tab completion keywords in psql?

From
Peter Eisentraut
Date:
On tor, 2012-05-03 at 15:47 -0400, Bruce Momjian wrote:
> Peter, where are we on this?

I hadn't received any clear feedback, but if no one objects, I can
commit it.

> ---------------------------------------------------------------------------
> 
> On Fri, Mar 30, 2012 at 08:16:59PM +0300, Peter Eisentraut wrote:
> > On fre, 2012-03-23 at 07:52 -0700, David Fetter wrote:
> > > On Thu, Mar 22, 2012 at 06:05:30PM -0400, Andrew Dunstan wrote:
> > > > On 03/22/2012 05:49 PM, Bruce Momjian wrote:
> > > > >Robert Haas and I are disappointed by this change.  I liked the
> > > > >fact that I could post nice-looking SQL queries without having to
> > > > >use my capslock key (which I use as a second control key).  Any
> > > > >chance of reverting this change?
> > > > >
> > > > 
> > > > Should it be governed by a setting?
> > > 
> > > Something like (upper|lower|preserve) ?
> > 
> > How about this patch then?  (There are actually four possible settings,
> > see patch.)




Re: Uppercase tab completion keywords in psql?

From
Bruce Momjian
Date:
On Fri, May 04, 2012 at 08:46:28PM +0300, Peter Eisentraut wrote:
> On tor, 2012-05-03 at 15:47 -0400, Bruce Momjian wrote:
> > Peter, where are we on this?
> 
> I hadn't received any clear feedback, but if no one objects, I can
> commit it.

I think there were enough people that wanted some kind of control in
this area.  I did give you feedback on the patch.

---------------------------------------------------------------------------

> > 
> > On Fri, Mar 30, 2012 at 08:16:59PM +0300, Peter Eisentraut wrote:
> > > On fre, 2012-03-23 at 07:52 -0700, David Fetter wrote:
> > > > On Thu, Mar 22, 2012 at 06:05:30PM -0400, Andrew Dunstan wrote:
> > > > > On 03/22/2012 05:49 PM, Bruce Momjian wrote:
> > > > > >Robert Haas and I are disappointed by this change.  I liked the
> > > > > >fact that I could post nice-looking SQL queries without having to
> > > > > >use my capslock key (which I use as a second control key).  Any
> > > > > >chance of reverting this change?
> > > > > >
> > > > > 
> > > > > Should it be governed by a setting?
> > > > 
> > > > Something like (upper|lower|preserve) ?
> > > 
> > > How about this patch then?  (There are actually four possible settings,
> > > see patch.)
> 
> 

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


Re: Uppercase tab completion keywords in psql?

From
Robert Haas
Date:
On Sat, May 5, 2012 at 9:03 AM, Bruce Momjian <bruce@momjian.us> wrote:
> On Fri, May 04, 2012 at 08:46:28PM +0300, Peter Eisentraut wrote:
>> On tor, 2012-05-03 at 15:47 -0400, Bruce Momjian wrote:
>> > Peter, where are we on this?
>>
>> I hadn't received any clear feedback, but if no one objects, I can
>> commit it.
>
> I think there were enough people that wanted some kind of control in
> this area.  I did give you feedback on the patch.

Yes, there were significantly more votes for reverting this than
keeping it.  So we at least need to have a setting.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


Re: Uppercase tab completion keywords in psql?

From
Devrim GÜNDÜZ
Date:
Hi,

On Mon, 2012-05-07 at 13:22 -0400, Robert Haas wrote:
> On Sat, May 5, 2012 at 9:03 AM, Bruce Momjian <bruce@momjian.us>
> wrote:
> > On Fri, May 04, 2012 at 08:46:28PM +0300, Peter Eisentraut wrote:
> >> On tor, 2012-05-03 at 15:47 -0400, Bruce Momjian wrote:
> >> > Peter, where are we on this?
> >>
> >> I hadn't received any clear feedback, but if no one objects, I can
> >> commit it.
> >
> > I think there were enough people that wanted some kind of control in
> > this area.  I did give you feedback on the patch.
>
> Yes, there were significantly more votes for reverting this than
> keeping it.  So we at least need to have a setting.

Can we do something about this before beta2 is bundled? I would like it
to be reverted though, rather than having a setting.

Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

Re: Uppercase tab completion keywords in psql?

From
Bruce Momjian
Date:
On Thu, May 31, 2012 at 04:06:50AM +0300, Devrim Gunduz wrote:
> Hi,
> 
> On Mon, 2012-05-07 at 13:22 -0400, Robert Haas wrote:
> > On Sat, May 5, 2012 at 9:03 AM, Bruce Momjian <bruce@momjian.us>
> > wrote:
> > > On Fri, May 04, 2012 at 08:46:28PM +0300, Peter Eisentraut wrote:
> > >> On tor, 2012-05-03 at 15:47 -0400, Bruce Momjian wrote:
> > >> > Peter, where are we on this?
> > >>
> > >> I hadn't received any clear feedback, but if no one objects, I can
> > >> commit it.
> > >
> > > I think there were enough people that wanted some kind of control in
> > > this area.  I did give you feedback on the patch.
> > 
> > Yes, there were significantly more votes for reverting this than
> > keeping it.  So we at least need to have a setting.
> 
> Can we do something about this before beta2 is bundled? I would like it
> to be reverted though, rather than having a setting.

A control variable was added in this commit:
commit db84ba65ab5c0ad0b34d68ab5a687bc5f4ca3ba6Author: Peter Eisentraut <peter_e@gmx.net>Date:   Tue May 8 21:03:45
2012+0300    psql: Add variable to control keyword case in tab completion    This adds the variable COMP_KEYWORD_CASE,
whichcontrols in what case    keywords are completed.  This is partially to let users configure the    change from
commit69f4f1c3576abc535871c6cfa95539e32a36120f, but it    also offers more behaviors than were available before.
 

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


Re: Uppercase tab completion keywords in psql?

From
Devrim GÜNDÜZ
Date:
Hi,

On Wed, 2012-05-30 at 22:03 -0400, Bruce Momjian wrote:
> A control variable was added in this commit:
>
>         commit db84ba65ab5c0ad0b34d68ab5a687bc5f4ca3ba6
>         Author: Peter Eisentraut <peter_e@gmx.net>

Thanks Bruce, apparently I missed it.

Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz