From: | Ken Johanson <pg-user(at)kensystem(dot)com> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Case Preservation disregarding case |
Date: | 2006-12-03 04:57:07 |
Message-ID: | 45725923.7010500@kensystem.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-sql |
Martijn van Oosterhout wrote:
> On Sat, Dec 02, 2006 at 11:08:51AM -0700, Ken Johanson wrote:
>>> And my vote is to not have such an option. But I'm not the one who
>>> decide so don't worry about what I think :-) I would like to have an
>>> option to upper case the identifiers instead of lower casing them as pg
>>> do. The sql standard say that they should be upper cased. But as far as
>>> I know there are no plan at the moment to add such an option either.
>>> Some time in the future I expect it to be implemented only because it's
>>> the standard.
>
> I think it's unlikely to happen anytime soon. The primary reason being
> that then you can no longer use indexes to search the catalog. Which
I'm pretty sure this is no the case - other DBs do allow index search on
columns/identifiers regardless of their case. Probably the typical
strategy is to use a case-insensitive hashtable (fold case for the keys
before generating the hash). If its the actual data that you're
referring to in index searches, that would be a separate topic I think.
> means it has to be fixed at initdb time. And it would break a large
> number of client apps, for no particularly good reason.
I take a different opinion on this:
-*If* the option to turn on case-insenetive behavior were selectable at
the DB or session level, the existing apps could continue to use the
case sensitve mode and be completely unaffected.
-IMO turning it on *globally* would only break apps that are built
case-sensitivly *and* refer to identifiers of the same name (but mixed
case) *and* are written for PG (since PG *had* been by and large
non-portable until recently.. the addition of standard string quoting
for example)
-It would *enhance* people's ability to "bring in" apps from so many
other DBs which don't treat identifiers as case sensitive. More of a
compatibility boon than loss. Thats is a particularly good reason to me
(since I'm the one who has to issue DDL on all my camelCase columns and
recode my identifiers).
>
> Since the way identifiers are treated is user-visible, it would mean
> that apps would have to be coded to work with any setting. What would
> probably happen is that app A would only work with case-sensetive, and
> app B would only work with case-insensetive, and you end up with two
> apps that can't work on the same database.
>
> That's *bad*, we don't want to go there.
That is a good point and I'd normally agree - entice people to use the
lowest common denominator behavior and code their apps case-sensitive.
And yet, the DBs that expect case-sens are now the minority, and we have:
a) programmers who code against MySQL or MSSQL, or;
b) are laymen try to run or port an app designed on MySQL to PG
Maybe not right per se - but the more popular way of doing things
eventually wins out.
..
>
>> In one way I think that even allowing creation of a separate "rowid" and
>> "rowId" sort of violates set theory in a 4+ GL language... a "name" in
>> its most abstract (human) sense doesn't (shouldn't) consider the case of
>> its characters. Only what the characters are. A rowid is also a rowId
>> (or ROWID). Who really intentionally mixes them? (only 3-4GL
>> *programmers* who consider all-caps to represent constants in my
>> experience).
>
> The thing is, postgresql *is* case-insensetive, as is the whole SQL
> language. It not case-preserving, that's all.
Right, it's case insensitive only if you're willing to accept case
folding (down) everything that's not quoted. Not being case-preserving,
as you say.
But thats a pita to anyone coming from those "other" DBs and wants their
column names to have mixed/camel case (for readability). PG right now
*forces* them to change/adhere to an underscore naming, or to quote
*every* mixed case identifier. You MUST tolerate having your column
names stored in all-lower case, or else you must quote all of them.
Best,
Ken
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-12-03 05:55:38 | Re: [HACKERS] Case Preservation disregarding case |
Previous Message | Tom Lane | 2006-12-03 04:36:15 | Re: PostgreSQL win32 fragmentation issue |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-12-03 05:55:38 | Re: [HACKERS] Case Preservation disregarding case |
Previous Message | Melvin Davidson | 2006-12-02 20:31:07 | Re: [SQL] Grants |