Re: Overcoming Initcap Function limitations?
От | Tom Lane |
---|---|
Тема | Re: Overcoming Initcap Function limitations? |
Дата | |
Msg-id | 848536.1701750235@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Overcoming Initcap Function limitations? (Steve Midgley <science@misuse.org>) |
Ответы |
Re: Overcoming Initcap Function limitations?
|
Список | pgsql-sql |
Steve Midgley <science@misuse.org> writes: > On Mon, Dec 4, 2023, 5:39 PM Bo Guo <bo.guo@gisticinc.com> wrote: >> Your suggestions open up new potentials for me to explore. At this >> moment, I lean towards normalizing the database column values in upper >> case, thereby out-sourcing the case-changing responsibility to the front >> end. I would love to hear from your thoughts on this pattern. > It really depends on the use case. If your users are happy with all > uppercase, that seems like a great solution: fast, cheap, and reliable! FWIW, as an old database geek I'd lean more towards "store the original input data". If you are expecting the client-side display code to transform the casing anyway, I don't see any advantage in smashing to upper case beforehand. And keeping the original casing could have value down the road, if only for forensic purposes. regards, tom lane
В списке pgsql-sql по дате отправления: