Re: Fwd: Camel case identifiers and folding

From: Chris Travers <chris(dot)travers(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Steve Haresnape <s(dot)haresnape(at)creativeintegrity(dot)co(dot)nz>, Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Fwd: Camel case identifiers and folding
Date: 2019-03-18 12:20:59
Message-ID: CAKt_ZftPpdSop=9S0eiTpDZbotZFYd0TRuxC7BOOR9nyK+GS5g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, Mar 16, 2019 at 3:15 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Steve Haresnape <s(dot)haresnape(at)creativeintegrity(dot)co(dot)nz> writes:
> > As I said, I don't want to quote my identifiers. I know what that does. I
> > want to specify them in a certain way, see them in that same way, but
> refer
> > to them in any old way.
> > You can call it normalize or fold or whatever. It's a bad design choice,
> > and not even a completely compliant choice.
>
> > Is a cure contemplated? I know it's not just me that dislikes this.
>
> No.
>
> There have been previous discussions of allowing variant case-folding
> rules, and the conclusion has always been that it would break so much
> stuff as to be entirely not worth the trouble.
>
> The big problem with making significant semantics changes like this
> be optional is that authors of general-purpose tools then have to be
> prepared to cope with all the possibilities. That's a pretty enormous
> cost to load onto other people. If it *only* affected the core code,
> maybe you could find somebody to do the work and call it done, but
> actually the implications would reverberate across the entire Postgres
> ecosystem. That's a tough call to make for a change that can't even
> be painted as meeting a widely-favored goal like better SQL spec
> compliance.
>

Yeah. I remember the annoyances caused by the removal of the implicit
casts in 8.3 and I think this would be orders of magnitude worse. The
cast changes were clearly worth the (significant) pain. I seriously doubt
changing case folding would.

>
> Now, in the spirit of full disclosure, I should say that the only form
> of this idea that people have really spent significant effort looking
> at is exactly the fully-SQL-spec-compliant case-folding rule, ie just
> like Postgres normally does it except unquoted identifiers fold to
> all-upper-case not all-lower. Perhaps there's some reason why what
> you want would be less painful than that turns out to be ... but I'm
> not seeing such a reason offhand. In fact I suspect your preference
> is actually worse, it'd require behavior changes in more places.
> As an example, I believe your request would require case-insensitive
> uniqueness enforcement in the system catalogs' unique indexes on names.
> You have no idea how large a can of worms that opens (but I'll just
> mention that "which characters are letters" doesn't even have a well
> defined universal answer).
>

+1

>
> regards, tom lane
>
>

--
Best Wishes,
Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Thomas Kellerer 2019-03-18 12:44:43 Re: Camel case identifiers and folding
Previous Message Chris Travers 2019-03-18 12:16:15 Re: Camel case identifiers and folding