Re: [SQL] id and ID in CREATE TABLE

On Sat, Jul 20, 2002 at 10:39:52AM +0300, stefan@extum.com wrote:

I forgot about "" Sorry. So if I would use names quoted then my questions
are obsolete. Except one:

So actually the only strange part would be PostgreSQL is folding to lower
cases a column name ...

[snip]

Why is like this ? Why not letting them upper case if they are not quoted
?

I think it's because many people think that uppercase column names suck. And
I agree with them. If you follow the given advice (either always quote
column names or never) then not only will your program work, it's will be
completely portable.

So, if you'd used your CREATE TABLE statememnt below, you wouldn't have had
this problem.

CREATE TABLE ttt (

ID int2,
name text );

--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Joshua b. Jore ; http://www.greentechnologist.org

On Sat, 20 Jul 2002 stefan@extum.com wrote:

Why is like this ? Why not letting them upper case if they are not quoted
?

stefan

Well.. this is because pgadmin created the attribute as "ID" originally so
for you - it's always been double-quoted to force the case. I never quote
my identifier literals just to avoid all the strange problems (like this)
that happen when you do it. It's just a bad idea.

Josh

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 ... at least in English; but I think the same would be
true of any language using an approximately Roman alphabet. The problem
with upper case is there's less variation in the overall letter shape.
If you don't care to dig in the academic literature about it, here's a
simple experiment: which of the following paragraphs do you find more
readable?

it's well established that all-lower-case text is more readable
than all-upper-case ... at least in english; but i think the
same would be true of any language using an approximately roman
alphabet. the problem with upper case is there's less variation
in the overall letter shape. if you don't care to dig in the
academic literature about it, here's a simple experiment: which
of the following paragraphs do you find more readable?

IT'S WELL ESTABLISHED THAT ALL-LOWER-CASE TEXT IS MORE READABLE
THAN ALL-UPPER-CASE ... AT LEAST IN ENGLISH; BUT I THINK THE
SAME WOULD BE TRUE OF ANY LANGUAGE USING AN APPROXIMATELY ROMAN
ALPHABET. THE PROBLEM WITH UPPER CASE IS THERE'S LESS VARIATION
IN THE OVERALL LETTER SHAPE. IF YOU DON'T CARE TO DIG IN THE
ACADEMIC LITERATURE ABOUT IT, HERE'S A SIMPLE EXPERIMENT: WHICH
OF THE FOLLOWING PARAGRAPHS DO YOU FIND MORE READABLE?

For me, at least, the second version takes noticeably more time to read
and is certainly less pleasant. (I suppose that for a non-native
speaker of English, mental translation might slow you down to the point
where you don't notice a difference. If so, try it on a random
paragraph in your own language.)

For PostgreSQL there is also a backwards compatibility issue: if we
change this decision now, we'd cause all kinds of problems for existing
code and databases.

Why then Oracle , IBM is using them and why the SQL standard is not
changed ?

The SQL standard's choice in this matter is prehistoric; undoubtedly
it falls out of the days when computer printers only had one type case.
IBM probably still has a residual fondness for those days ;-). But
the rest of the industry figured out that lower case was better
somewhere around 1960, cf Algol-60 which was the first language to spell
its keywords preferentially in lower case.

regards, tom lane

stefan@extum.com wrote:

I forgot about "" Sorry. So if I would use names quoted then my questions
are obsolete. Except one:

So actually the only strange part would be PostgreSQL is folding to lower
cases a column name ...

From docs:

The folding of unquoted names to lower case in PostgreSQL is
incompatible with the SQL standard, which says that unquoted names should
be folded to upper case. Thus, foo should be equivalent to "FOO" not
"foo" according to the standard. If you want to write portable
applications you are advised to always quote a particular name or never
quote it.

Why is like this ? Why not letting them upper case if they are not quoted
?

Well, historically, we always did lower case, and all-upper case looks
ugly. That's about it.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
Tom Lane wrote:<br>
<blockquote type="cite" cite="mid12220.1027085465@sss.pgh.pa.us">
<pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:stefan@extum.com">stefan@extum.com</a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">But anyway this is not so important, but why upper cases are bad ?
</pre>
</blockquote>
<pre wrap=""><!---->
It's well established that all-lower-case text is more readable than
all-upper-case ... at least in English; but I think the same would be
true of any language using an approximately Roman alphabet. The problem
with upper case is there's less variation in the overall letter shape.
If you don't care to dig in the academic literature about it, here's a
simple experiment: which of the following paragraphs do you find more
readable?

it's well established that all-lower-case text is more readable
than all-upper-case ... at least in english; but i think the
same would be true of any language using an approximately roman
alphabet. the problem with upper case is there's less variation
in the overall letter shape. if you don't care to dig in the
academic literature about it, here's a simple experiment: which
of the following paragraphs do you find more readable?

IT'S WELL ESTABLISHED THAT ALL-LOWER-CASE TEXT IS MORE READABLE
THAN ALL-UPPER-CASE ... AT LEAST IN ENGLISH; BUT I THINK THE
SAME WOULD BE TRUE OF ANY LANGUAGE USING AN APPROXIMATELY ROMAN
ALPHABET. THE PROBLEM WITH UPPER CASE IS THERE'S LESS VARIATION
IN THE OVERALL LETTER SHAPE. IF YOU DON'T CARE TO DIG IN THE
ACADEMIC LITERATURE ABOUT IT, HERE'S A SIMPLE EXPERIMENT: WHICH
OF THE FOLLOWING PARAGRAPHS DO YOU FIND MORE READABLE?

For me, at least, the second version takes noticeably more time to read
and is certainly less pleasant. (I suppose that for a non-native
speaker of English, mental translation might slow you down to the point
where you don't notice a difference. If so, try it on a random
paragraph in your own language.)</pre>
</blockquote>
It's a pattern recognition issue.&nbsp;&nbsp; Taken in context with your reading experience
and the general constructs of the English language in addition common usage,
you encounter far more lower case letters than upper case letters.&nbsp; It makes
sense that it would be easier to recognize the words in all lower case.&nbsp;
Secondly, your brain expects lower case letters behind the leading upper
case letter for the word.&nbsp;&nbsp; So in a sense you backtrack just a little because
it doesn't match what you expect.&nbsp;&nbsp; I'm not discounting the statements you
made, but this is one additional observation.<br>
<br>
[ In the previous paragraph there were 6 capital letters to the 471 non-capital
letters. ]<br>
<blockquote type="cite" cite="mid12220.1027085465@sss.pgh.pa.us">
<pre wrap="">

For PostgreSQL there is also a backwards compatibility issue: if we
change this decision now, we'd cause all kinds of problems for existing
code and databases.

</pre>
<blockquote type="cite">
<pre wrap="">Why then Oracle , IBM is using them and why the SQL standard is not
changed ?
</pre>
</blockquote>
<pre wrap=""><!---->
The SQL standard's choice in this matter is prehistoric; undoubtedly
it falls out of the days when computer printers only had one type case.
IBM probably still has a residual fondness for those days ;-). But
the rest of the industry figured out that lower case was better
somewhere around 1960, cf Algol-60 which was the first language to spell
its keywords preferentially in lower case.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

<a class="moz-txt-link-freetext" href="http://www.postgresql.org/users-lounge/docs/faq.html&quot;&gt;http://www.postgresql.org/users-lounge/docs/faq.html&lt;/a&gt;
</pre>
</blockquote>
<br>
<br>
</body>
</html>

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.

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?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

"scott.marlowe" <scott.marlowe@ihs.com> writes:

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

The main problem with this is what do you do with the system catalogs?
If we start folding to upper case then existing clients will break
unless we also rename pg_class to PG_CLASS, etc; and that will break
them anyway if they wrote "pg_class".

I don't believe that conforming to this particular small aspect of the
spec is worth the pain it would cause.

regards, tom lane

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?

On Fri, 19 Jul 2002, Tom Lane wrote:

"scott.marlowe" <scott.marlowe@ihs.com> writes:

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

The main problem with this is what do you do with the system catalogs?
If we start folding to upper case then existing clients will break
unless we also rename pg_class to PG_CLASS, etc; and that will break
them anyway if they wrote "pg_class".

I don't believe that conforming to this particular small aspect of the
spec is worth the pain it would cause.

But it's not a small aspect if it means someone either can't use an app
with postgresql because it was written to spec, or someone has to spend
a bunch of time rewriting all their queries to work with postgresql.

I'm not talking about something I'd want on all my tables or all my
databases, but there are many instances (look over this list's archive and
you'll see them) where following spec would help migration issues.

Plus the pg_class stuff is kind of a blind ally. If we're looking at
foldtoupper as a setting, then we're already admitting that we're doing it
to be interchangable with other dbmses. If that's the case, no one is
gonna be accessing the pg_* tables, because you wouldn't do that in an app
you're writing to be portable. And if you're migrating to postgresql, you
won't have anything there that would access pg_* as well.

Leave the system catalogs in lower case, and don't fold calls to anything
that's a system catalog. Or wrap them all to upper if the fold to upper
is set. I don't see this being a setting that many people would change,
but then again, most people don't change sql_inheritance or
transform_nulls_equals but their both there for the same reason as what
I'm talking about. Some other databases do things a little differently,
and if we want to be a drop in replacement, we can either accomodate them
or thumb our noses at them and tell them it's not our problem.

In all honesty, this change is more "right" than transform_nulls_equals
since transform_nulls_equals makes postgresql BREAK the SQL standard, and
this one would make it follow it.

On Fri, 19 Jul 2002, scott.marlowe wrote:

On Fri, 19 Jul 2002, Tom Lane wrote:

"scott.marlowe" <scott.marlowe@ihs.com> writes:

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

The main problem with this is what do you do with the system catalogs?
If we start folding to upper case then existing clients will break
unless we also rename pg_class to PG_CLASS, etc; and that will break
them anyway if they wrote "pg_class".

I don't believe that conforming to this particular small aspect of the
spec is worth the pain it would cause.

But it's not a small aspect if it means someone either can't use an app
with postgresql because it was written to spec, or someone has to spend
a bunch of time rewriting all their queries to work with postgresql.

Presumably that's only true if they're mixing quoted and unquoted
identifiers, which is a bad idea in any case (since what happens to "foo"
and foo - do you trust somebody who's mixing them to get it right
everywhere :) ?) or their application is using the names returned
elsewhere (which is a problem with doing it as lower).

If
create table FOO(col1 int, Col2 int, cOL3 int);
select COL1 from foo;
failed, I think people would be more interested in changing it.

"scott.marlowe" <scott.marlowe@ihs.com> writes:

Plus the pg_class stuff is kind of a blind ally. If we're looking at
foldtoupper as a setting, then we're already admitting that we're doing it
to be interchangable with other dbmses. If that's the case, no one is
gonna be accessing the pg_* tables, because you wouldn't do that in an app
you're writing to be portable.

<< thinks about that for awhile >>

Hmm. If we are willing to stipulate that the system catalogs stay named
as they are (lower case always), then we could indeed have a runtime
parameter (GUC setting) that controls how individual sessions fold case.
People who need to access the system catalogs regardless can just
double-quote their names.

One fly in the ointment is that we are planning to add the standard's
INFORMATION_SCHEMA views someday, and neither choice of case is going to
be good for them if we have an option like this floating around. Not
sure what to do about that, although I suppose one way out is to provide
two duplicate sets of those views (one named all-upper-case, the other
all-lower).

I think your four-way proposal is gilding a dead lily, though. Let's
just do the historical (downcase) and spec-compatible (upcase) options.
Anything else will just create more confusion, IMHO. The
case-insensitive option is a particularly *bad* idea.

Note it would be a real good idea to fix psql and pg_dump to
double-quote their references to system catalogs, so they don't go
belly-up if invoked on a database where FOLDTOUPPER is true.
(pg_dump could alternatively do SET FOLDTOUPPER = false, but this won't
fly for psql.)

Leave the system catalogs in lower case, and don't fold calls to anything
that's a system catalog.

And you will determine that how, exactly, when you don't know what the
identifier (that you haven't parsed yet) refers to?

Keep it simple, or you'll make things far worse than they are now.

regards, tom lane

Thanks all for comments. In Oracle and DB2 as far as I know the upper case
column names are used when you have no columns quoted.. Indeed it is
recommended to use lower cases to
avoid mistakes and confusion during porting. Is that right ?

But anyway this is not so important, but why upper cases are bad ?
Why then Oracle , IBM is using them and why the SQL standard is not
changed ?

stefan

On Fri, 19 Jul 2002, Martijn van Oosterhout wrote:

Well I think I have got the point. True indeed if I would read also in my
language, romanian, then I would choose lower-case.

I bet there are more interesting things what you guys are working on and
I was just curious to ask. I understood replication would be a major
benefit to have in 7.3 and as well, maybe, ALTER TABLE fully implemented
as SQL92 ?

stefan

On Fri, 19 Jul 2002, Bruce Momjian wrote: