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