On Apr 24, 2004, at 11:17, Jan Wieck wrote:
> 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