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
|
Список | 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 по дате отправления: