Re: The case for preserving case. - Mailing list pgsql-hackers

From emf
Subject Re: The case for preserving case.
Date
Msg-id B1CE1A36-965A-11D8-8E4B-000A959B1F9A@mindlace.net
Whole thread Raw
In response to The case for preserving case.  (emf <pgsql@mindlace.net>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: emf
Date:
Subject: Re: The case for preserving case.
Next
From: Gaetano Mendola
Date:
Subject: Re: Invalid pg_hba.conf => Postgres crash