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
