Re: [HACKERS] case_preservation_and_insensitivity = on

Поиск
Список
Период
Сортировка
От Joel Jacobson
Тема Re: [HACKERS] case_preservation_and_insensitivity = on
Дата
Msg-id CAASwCXf6JkSRr0hVXM+TJNFYzb4Euuc_mL-=BVRiYK00sgThbQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] case_preservation_and_insensitivity = on  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] case_preservation_and_insensitivity = on  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, Feb 16, 2017 at 6:53 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Have you read any of our innumerable previous discussions about this?

No, sorry, didn't see them, thanks for sharing the links.

> The short answer is that nobody can see a way to modify the identifier
> case-folding rules that isn't going to add more pain than it subtracts.
> And much of the added pain will be felt by people who aren't getting
> any benefit, who will therefore be vociferously against the whole thing.

I've read the discussion and have an idea:

When case preservation by default is on, then simply enforce
UNIQUE(LOWER(object_name)), to prevent ambiguity.

If all objects lowercase names are unique, but the casing is
preserved, then a user who later on suffers from problems with
external tools that work poorly with non-lowercase object names, could
then simply switch back to lowercase object names by changing the GUC.

OTOH, if not enforcing lowercase uniqueness, there would be a risk two
objects with different casing would have conflicting lowercase names,
and then the user who later runs into problems with some external tool
would have a serious problem, since switching to lowercase would not
be an option.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: [HACKERS] duplicate "median" entry in doc
Следующее
От: Fabien COELHO
Дата:
Сообщение: [HACKERS] Small issue in online devel documentation build