Re: [HACKERS] case_preservation_and_insensitivity = on - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] case_preservation_and_insensitivity = on
Date
Msg-id CA+TgmoZWoLf389kyK_of14zXMx6hLyCnijifSHp99Ng66ewnSw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] case_preservation_and_insensitivity = on  (Joel Jacobson <joel@trustly.com>)
List pgsql-hackers
On Fri, Feb 24, 2017 at 11:04 PM, Joel Jacobson <joel@trustly.com> wrote:
> On Thu, Feb 23, 2017 at 8:04 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> It doesn't sound like a good solution to me, because there can be SQL
>> code inside stored procedures that clients never see.
>
> In our code base, we use CamelCase in all PL/pgSQL functions, both for
> columns and variables,
> e.g. SELECT UserID INTO _UserID FROM Users WHERE Username = 'foo';
>
> Here, it's not a problem that the column name is e.g. "userid",
> since the case-insensitive feature makes it work.
>
> What type of case problem do you foresee for stored procedures?

If we did something on the server-side, stored procedures would be
handled just like everything else, so stored procedures would suffer
or be unaffected to precisely the same extent as anything else.
However, Tom proposed doing the case-remapping on the client side,
which would cause the behavior to be one thing for queries submitted
directly from the client and something else for queries that appear
inside PL code.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] UPDATE of partition key
Next
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)