Re: [HACKERS] case_preservation_and_insensitivity = on

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] case_preservation_and_insensitivity = on
Дата
Msg-id CA+TgmoZWoLf389kyK_of14zXMx6hLyCnijifSHp99Ng66ewnSw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] case_preservation_and_insensitivity = on  (Joel Jacobson <joel@trustly.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] UPDATE of partition key
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)