On Mon, Feb 20, 2017 at 2:40 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> Even if the project decided that "Users" and users is stupid and that we
> should deprecate it, I think the odds of also deciding to tell existing
> users to re-write their apps are zero.
But if the feature can't be turned on without also enforcing lowercase
uniqueness,
then the described problem situation will never happen.
Any existing projects who want to use the new feature but can't due to
conflicting names,
will simply just have to live without it, just like they already do.
> So no matter how this is designed, there has to be some way for existing
> users to be able to continue relying on "Users" and users being different.
There is a way, simply don't switch on the feature,
and "Users" and "users" will continue to be different.
> What would work is an initdb option that controls this: when ignoring case
> for uniqueness is disabled, your new column would simply be left as NULL.
> With some extra effort you could probably allow changing that on a running
> database as well, just not with something as easy to change as a GUC.
initdb option sounds good to me, just like you specify e.g. --encoding.
Also, I think the --lowercase-uniqueness feature would be useful by
itself even without the --case-preserving feature,
since that might be a good way to enforce a good design of new databases,
as a mix of "users" and "Users" is probably considered ugly by many
system designers.