Re: [SQL] id and ID in CREATE TABLE

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <stefan(at)extum(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, <pgsql-sql(at)postgresql(dot)org>, <pgsql-general(at)postgresql(dot)org>
Subject: Re: [SQL] id and ID in CREATE TABLE
Date: 2002-07-19 19:15:37
Message-ID: Pine.LNX.4.44.0207191259400.3990-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-sql

On Fri, 19 Jul 2002, Bruce Momjian wrote:

> scott.marlowe wrote:
> > On Fri, 19 Jul 2002, Tom Lane wrote:
> >
> > > stefan(at)extum(dot)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?

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Mike Mascari 2002-07-19 19:20:55 Re: Multi-Versions and Vacuum -- cf Oracle & Vacuum alt
Previous Message Mike Mascari 2002-07-19 19:15:05 Re: Multi-Versions and Vacuum -- cf Oracle & Vacuum alt

Browse pgsql-sql by date

  From Date Subject
Next Message Patrick Hatcher 2002-07-19 19:26:08 Re: Is it possible to use a field from another table as part of a
Previous Message Josh Berkus 2002-07-19 18:58:20 Re: Two Index Questions