From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Steve Midgley <science(at)misuse(dot)org> |
Cc: | Bo Guo <bo(dot)guo(at)gisticinc(dot)com>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, pgsql-sql <pgsql-sql(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Overcoming Initcap Function limitations? |
Date: | 2023-12-05 04:23:55 |
Message-ID: | 848536.1701750235@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Steve Midgley <science(at)misuse(dot)org> writes:
> On Mon, Dec 4, 2023, 5:39 PM Bo Guo <bo(dot)guo(at)gisticinc(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2023-12-05 20:54:08 | Re: Overcoming Initcap Function limitations? |
Previous Message | Steve Midgley | 2023-12-05 04:12:34 | Re: Overcoming Initcap Function limitations? |