Hi EMF,
emf wrote:
> Hello, postgresql hackers.
> All of this breaks when I start to use postgresql, because all of the
> attributes become lowercased.
Well, I'm afraid that something will have to change in the app. Your
email arrives while we are in the middle of a small war around the
subject of case changing, but none of the options going around at the
moment will match your request.
The two options considered are leaving things as they are (con: non
standard complient) or folding to uppercase (con: ugly and requires
transition, unfortunetly, in this order).
>
> Fixing this problem involves one of three things:
>
> 1.) rewriting all the code to have lowercased identifiers. This is
> effectively renaming everything, as long camel case attributes become
> much harder to read when they're lowercased. This also changes the
> clients' preferred coding standard.
Ok, so don't do it.
> 2.) using double quotes around all identifiers in sql statements. As
> you're probably aware, there's no string format in PHP that lets you
> write double quote marks unescaped (and do variable substitution), so
> this involves rewriting hundreds of lines and imposing ongoing
> overhead for every SQL query.
But is consistant with both SQL standard, and with current MySQL setup.
This will also make porting the app to further database, such as
commercial ones, easier. I think that is the proper way or you to go.
>
> 3.) escaping 4 lines in src/backend/parser/scansup.c , where
> identifiers are lowercased.
You can do that for your own postgres installation, if you really like.
I'm not a member of the steering commitee, but I doubt you'll manage to
get such a patch accepted. Maybe as a per-session setting....
>
> I understand that the reason for lowercasing is because odbc
> connections, etc expect case insensitivity, but the current behaviour
> isn't an SQL standard
Neither is yours, though. If we are going to change it, we might as well
change it to the standard, don't you think?
> nor is it really case insensitivity.
It's as close as you can get without losing the benefits of doing hash
lookups.
> I would love case insensitivity with case preservation, but since that
> evidently is a more complicated option, I would like to know how I can
> formulate the 'case preserving' option in a way to make it palatable
> for inclusion.
Can't help you there, unless you want to compile Postgres yourself.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/
