From: scott.marlowe <scott.marlowe@ihs.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: stefan@extum.com
Cc: Martijn van Oosterhout <kleptog@svana.org>
Cc: pgsql-sql@postgresql.org
Cc: pgsql-general@postgresql.org
Subject: Re: [SQL] id and ID in CREATE TABLE
Date: Fri, 19 Jul 2002 13:15:37 -0600 (MDT)
Message-ID: <Pine.LNX.4.44.0207191259400.3990-100000@css120.ihs.com> (raw)
In-Reply-To: <200207191729.g6JHTGD29488@candle.pha.pa.us>
On Fri, 19 Jul 2002, Bruce Momjian wrote:
> scott.marlowe wrote:
> > On Fri, 19 Jul 2002, Tom Lane wrote:
> >
> > > stefan@extum.com writes:
> > > > But anyway this is not so important, but why upper cases are bad ?
> > >
> > > It's well established that all-lower-case text is more readable than
> > > all-upper-case ...
> >
> > Agreed. Absolutely. But, since the SQL standard says upper case,
> > wouldn't it be useful to at least have a switch (run time, initdb time,
> > or ./configure time???) called something like FOLDTOUPPER (in upper case
> > of course :-)
> >
> > If it's an easy win I'd be willing to do it. I'm not the world's greatest
> > C hacker, but I still remember enough of it to be competant.
>
> Yea, I guess we could. I think the consensus is that the uppercase
> default is so weird, we don't know anyone who would want to use it.
> Would you?
Not if I had a choice. But it isn't about what I want or what you want,
it's about doing what makes postgresql the most useful for the most
people. I can see many situations where this would make postgresql a
better choice than it is right now for certain projects, like:
writing an app to be as portable as possible (i.e. the reason we have
standards...)
-or-
migrating from some other database that follows the standard (oracle
does I believe) and don't want to go in and re-write SQL queries from all
the front end apps that hit the database.
-or-
making closed source database mining tools more likely to get along with
postgresql
I can think of a lot of reasons people could desire this, even though I
myself would prefer to NOT have upper case.
My other thought on it was whether we could make it case insensitive.
Again, settable by some switch. It could attribute names in mixed case,
but all comparisons would be done in upper or lower case. But I don't
know how much that would cost us in processing power, especially if it had
to fold case based on locale where we can't just use a simple bit flip to
make everything lower or upper case when parsing it.
By the way, there have been messages about the problems with case folding
in this mailing list for the last six months about once a month, so if
there was a simple switch to make it behave the way people need it to
behave instead of the way it currently behaves, answering those questions
would be as easy as pointing to the right place in the docs.
So, I would propose a run time setting that has the four possible
settings:
case_handling:
fold_to_lower (default)
fold_to_upper (i.e. SQL92/99 compatibility mode)
case_insensitive (this one may be more work than it's worth)
case_sensitive (i.e. unix mode)
If case insensitive were implemented it I would recommend we do in a way
that allows the database to store the tables in mixed case as put in, but
parse internally on lower or upper case only.
Is local an issue, or does postgresql expect you to do everything in ascii
8 bit with no funny chars in attribute names?
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: pgsql-sql@postgresql.org
Cc: scott.marlowe@ihs.com, pgman@candle.pha.pa.us, tgl@sss.pgh.pa.us, stefan@extum.com, kleptog@svana.org, pgsql-general@postgresql.org
Subject: Re: [SQL] id and ID in CREATE TABLE
In-Reply-To: <Pine.LNX.4.44.0207191259400.3990-100000@css120.ihs.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox