Re: Bringing PostgreSQL torwards the standard regarding case folding

Shachar,

I've been giving this some more thought.  Here are my contributions:

> 1. Setting should be on a per-database level. A per-server option is not
> good enough, and a per-session option is too difficult to implement,
> with no apparent justifiable return.

I disagree with this.  I think doing case-folding per database would be 
preposterously difficult, and that per-server is adequate.   Per database 
settings bring up a whole raft of logical conflicts, particularly around the 
system catalogs and dblink, that aren't necessarily worth navigating.

I also didn't follow the discussion of why a client-side implementation was 
technically impossible; this seems like the most obvious course to me, and to 
have *considerable* benefit.    It's also consistent with our other statement 
variables, such as datestyle, which are all client-side, per-session 
settings.   

A server-side implementation would possibly reqire touching every single 
source code file in Postgres, something that would justify a lot of effort to 
avoid.

> 2. Old applications already working with PG's lowercase folding should
> have an option to continue working unmodified for the foreseeable future.

Si.

> 1. Tri-state. Folder upper, if failes, fold lower, if succeeds, warn.

Can't see this being possible.

> 2. Dual state. Fold lower or upper. Break if client is broken.

Best, I think.  But it should be client-side.

> 3. Create a database conversion tool to change existing case.

No thanks.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco