Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. psql: Add variable to control keyword case in tab completion

  2. psql: Case preserving completion of SQL key words

  1. Uppercase tab completion keywords in psql?

    Bruce Momjian <bruce@momjian.us> — 2012-03-22T21:49:55Z

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

  2. Re: Uppercase tab completion keywords in psql?

    Andres Freund <andres@anarazel.de> — 2012-03-22T21:56:00Z

    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

  3. Re: Uppercase tab completion keywords in psql?

    Andrew Dunstan <andrew@dunslane.net> — 2012-03-22T22:05:30Z

    
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

  4. Re: Uppercase tab completion keywords in psql?

    Alvaro Herrera <alvherre@commandprompt.com> — 2012-03-23T14:51:16Z

    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

  5. Re: Uppercase tab completion keywords in psql?

    David Fetter <david@fetter.org> — 2012-03-23T14:52:00Z

    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

  6. Re: Uppercase tab completion keywords in psql?

    David Fetter <david@fetter.org> — 2012-03-23T14:53:19Z

    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

  7. Re: Uppercase tab completion keywords in psql?

    Peter Geoghegan <peter@2ndquadrant.com> — 2012-03-23T15:07:24Z

    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

  8. Re: Uppercase tab completion keywords in psql?

    Andrew Dunstan <andrew@dunslane.net> — 2012-03-23T15:13:23Z

    
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

  9. Re: Uppercase tab completion keywords in psql?

    Tom Lane <tgl@sss.pgh.pa.us> — 2012-03-23T15:20:07Z

    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

  10. Re: Uppercase tab completion keywords in psql?

    Peter Geoghegan <peter@2ndquadrant.com> — 2012-03-23T15:35:25Z

    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

  11. Re: Uppercase tab completion keywords in psql?

    Peter Eisentraut <peter_e@gmx.net> — 2012-03-30T17:16:59Z

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

  12. Re: Uppercase tab completion keywords in psql?

    Bruce Momjian <bruce@momjian.us> — 2012-04-11T02:35:37Z

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

  13. Re: Uppercase tab completion keywords in psql?

    Bruce Momjian <bruce@momjian.us> — 2012-05-03T19:47:48Z

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

  14. Re: Uppercase tab completion keywords in psql?

    Peter Eisentraut <peter_e@gmx.net> — 2012-05-04T17:46:28Z

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

  15. Re: Uppercase tab completion keywords in psql?

    Bruce Momjian <bruce@momjian.us> — 2012-05-05T13:03:38Z

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

  16. Re: Uppercase tab completion keywords in psql?

    Robert Haas <robertmhaas@gmail.com> — 2012-05-07T17:22:35Z

    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

  17. Re: Uppercase tab completion keywords in psql?

    Devrim Gündüz <devrim@gunduz.org> — 2012-05-31T01:06:50Z

    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

  18. Re: Uppercase tab completion keywords in psql?

    Bruce Momjian <bruce@momjian.us> — 2012-05-31T02:03:00Z

    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 db84ba65ab5c0ad0b34d68ab5a687bc5f4ca3ba6
	Author: 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, 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@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

  19. Re: Uppercase tab completion keywords in psql?

    Devrim Gündüz <devrim@gunduz.org> — 2012-05-31T06:21:03Z

    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