Re: Overcoming Initcap Function limitations?

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

In response to

Responses

Browse pgsql-sql by date

  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?