The case for preserving case.

Hello, postgresql hackers.

I am working with a client with a 20k record MySQL database (that will 
shortly expand to 100k/1m) and a few thousand lines of PHP code that 
does a lot of DB interaction.

Their application, with a lot of relationships between data and a bunch 
of data integrity requirements is perfectly suited to postgresql.

The PHP code follows a coding standard wherein variables are assigned 
CamelCase identifiers. All of the objects persist themselves to the DB, 
with a variable per column; on object initialization db columns are 
read from the db and added as attributes of the object.

All of this breaks when I start to use postgresql, because all of the 
attributes become lowercased.

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.

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.

3.) escaping 4 lines in src/backend/parser/scansup.c , where 
identifiers are lowercased.

I understand that the reason for lowercasing is because odbc 
connections, etc expect case insensitivity, but the current behaviour 
isn't an SQL standard nor is it really case insensitivity. 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.
--
nothing can happen inside a sphere
that you could not inscribe upon it.
~mindlace        http://mindlace.net