| 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: | Whole Thread | Raw Message | 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? |