Re: Uppercase tab completion keywords in psql?

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(at)gmx(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

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(at)gmx(dot)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

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

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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)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 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(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)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 22 March 2012 22:05, Andrew Dunstan <andrew(at)dunslane(dot)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

On 03/23/2012 11:07 AM, Peter Geoghegan wrote:
> On 22 March 2012 22:05, Andrew Dunstan<andrew(at)dunslane(dot)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

Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
> On 22 March 2012 22:05, Andrew Dunstan <andrew(at)dunslane(dot)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

On 23 March 2012 15:13, Andrew Dunstan <andrew(at)dunslane(dot)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

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

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

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

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On Sat, May 5, 2012 at 9:03 AM, Bruce Momjian <bruce(at)momjian(dot)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

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(at)momjian(dot)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

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(at)momjian(dot)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 db84ba65ab5c0ad0b34d68ab5a687bc5f4ca3ba6
Author: Peter Eisentraut <peter_e(at)gmx(dot)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, which controls in what case
keywords are completed. This is partially to let users configure the
change from commit 69f4f1c3576abc535871c6cfa95539e32a36120f, but it
also offers more behaviors than were available before.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

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(at)gmx(dot)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