Re: case_preservation_and_insensitivity = on

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Joel Jacobson <joel(at)trustly(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: case_preservation_and_insensitivity = on
Date: 2017-02-26 07:19:42
Message-ID: CA+TgmoZWoLf389kyK_of14zXMx6hLyCnijifSHp99Ng66ewnSw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 24, 2017 at 11:04 PM, Joel Jacobson <joel(at)trustly(dot)com> wrote:
> On Thu, Feb 23, 2017 at 8:04 AM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2017-02-26 07:47:22 Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)
Previous Message Robert Haas 2017-02-26 07:15:30 Re: UPDATE of partition key