public inbox for [email protected]  

help / color / mirror / Atom feed

From: Dennis Bjorklund <[email protected]>
To: Tom Lane <[email protected]>
Cc: Stephan Szabo <[email protected]>
Cc: Shachar Shemesh <[email protected]>
Cc: Robert Treat <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: PostgreSQL advocacy <[email protected]>
Subject: Re: [HACKERS] What can we learn from MySQL?
Date: Sat, 24 Apr 2004 06:38:58 +0200 (CEST)
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On Sat, 24 Apr 2004, Tom Lane wrote:

> Upper-case-only sucks, by every known measure of readability, and I
> don't want to have to put up with a database that forces that
> 1960s-vintage-hardware mindset on me.

Well, get used to it :-)

> So what I'm holding out for is a design that lets me continue to see the
> current behavior if I set a GUC variable that says that's what I want.

Wouldn't the upper case identifiers just be visible in the \d output,
table headers and such. You could still have psql tab completion produce
lower case identifiers (if told using some setting).

Even if the database store all non quoted names as upper case I would 
still use lower case in all applications and on the psql command line.

It's not a big problem for me if the output of \d and the table headers
and such is in upper case. One would get used to it fase. And maybe one
can even store an extra bit telling if the string was created with or
without quotes and have psql lower case all the ones created without
quotes.

First I thought that one can store the string with case all the time, and
just convert when needed (when comparing identifiers). Perhaps using the
non existant locale support and locales such as SQL_UPPER or SQL_MIXED.
But it wont work since it would make "Foo" and Foo clash. When translated
directly it would create separate entries "Foo" and "FOO".

ps. And if you want to play the WRITE MAILS USING ONLY UPPER CASE, BE MY 
GUEST!

-- 
/Dennis Björklund

view thread (145+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: [HACKERS] What can we learn from MySQL?
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox