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