On 2/19/17 4:51 PM, Joel Jacobson wrote:
But once you've already
decided to have a hard-and-fast rule that the names must be unique
after lower-casing, there's no obvious benefit to rejecting queries
that mention the same name with different case.
Exactly, that trade-off is necessary, otherwise such queries would be ambiguous.
I think a good general philosophy for the PostgreSQL project would be to
try to look at how to meed the needs for new users of new projects
in a way that don't impair things for existing users,
by accepting the new users might have to live with some trade-offs
for their new feature to be possible to implement,
such as in this case that the trade-off is to not be able to create
objects of different casing with the same lowercase names,
a tradeoff that I personally think would not be a problem for most projects,
since it seems unlikely you would both have a "users" table and a
"Users" table in the same database.
There's a serious problem with that, though: there certainly *could* be
existing users that depend on the difference between "Users" and users,
and there's no way we can just leave them out in the cold.
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.
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. AFAICT that rules out any chance of this being a GUC, because
you can't take a GUC into consideration when creating a unique index.
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.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
