Обсуждение: 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 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. +
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
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@commandprompt.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@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 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
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
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
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
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
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@momjian.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@momjian.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@momjian.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@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
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
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. +
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