I don't think that we will break backward compatibility for existing PostgreSQL specific code in order to gain CamelCase+MySQL porting ease by adopting an even less standard compliant behaviour than we currently have.
I understand and agree that breaking backward compatibility is not an option.
As things are today, we are case insensitive for unquoted identifiers and breaking that is not an option.
What you do to unquoted identifiers is not case insensitivity, but lowercase folding.
I see a chance for getting your desired behaviour, case preservation, only as a side effect if a larger move towards the standard.
That sounds great! I'd like to help if I can.
This would not be a simple per postmaster config option or even a compiletime setting, but rather a per database option in the pg_database system catalog, chosen at CREATE DATABASE time.
This also sounds good, but with my vast ignorance of postgresql, I have no idea the proper way to tell scansup.c to knock it off (or fold up, or fold down) based on something in the pg_database system catalog.
The real problem with this is that it has far greater side effects than you seem to imagine yet.
[snip described problem] I am probably still not understanding, since if the internals always quote in their queries, it would seem that the internals could continue to use lowercase identifiers regardless of the DB setting.
I am certain that most of us are open for a more complete proposal that includes moving towards the ANSI standard, but the change you outlined below is not acceptable.
I understand that. I am willing to do work to make a more complete proposal, but I would appreciate some guidance as to how to code something that would be more acceptable. I read in another thread that the stuff going on in scansup.c isn't allowed/shouldn't talk to the database, so I freely admit I don't know how to approach a palatable solution.
Worst case scenario, I'm content with keeping my hacked version of postgresql so that I can get this application ported faster. Making that happen fast and taking advantage of postgresql's superior features will help convince my client that the thousands of dollars he's spending in this port were worthwhile ... once I've done that, gradually transitioning to case-insensitive identifiers is possible, but right now all he sees is big transition pain for gain he hasn't seen yet.
--
nothing can happen inside a sphere
that you could not inscribe upon it.
~mindlace http://mindlace.net
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
