Экранирование одинарных кавычек в предложении PLACEHOLDER оператора SQL HANA - PullRequest
Новая
       8

Экранирование одинарных кавычек в предложении PLACEHOLDER оператора SQL HANA

0 голосов
/ 18 декабря 2018

Я заметил несоответствие в том, как «HANA SQL» экранирует одинарные кавычки в контексте предложения PLACEHOLDER.Например, рассмотрим следующий фрагмент предложения PLACEHOLDER:

('PLACEHOLDER' = ('$$CC_PARAM$$','''foo'',''an escaped single quote \'' '''))

Предложение PLACEHOLDER, приведенное выше, содержит несколько значений, присвоенных CC_PARAM.параметр.Мы можем видеть, что внутри второго аргумента у нас есть одиночная кавычка, которая экранирована обратной косой чертой.Однако мы избегаем одинарных кавычек вне каждого аргумента с другой одинарной кавычкой (т.е. мы делаем '' вместо \''. Возможно использовать формат \'' для первого случая, но это не такможно использовать формат '' во втором случае.

Почему существует это несоответствие? Это затрудняет экранирование кавычек во входных параметрах с несколькими входами. Я ищу программно создавать запросы SQL для HANA.Я что-то здесь упустил? Безопасно ли использовать \'' над '' во всех случаях? Или мне нужна логика, которая может определить, где встречается одиночная кавычка, и выбрать нужное значение?

1 Ответ

0 голосов
/ 18 декабря 2018

Здесь неявное правило, определяемое тем, как реализовано программное обеспечение, заключается в том, что для значений параметров представлений вычислений обратная косая черта \ используется для экранирования одинарных кавычек.

Для всех стандартных строк SQLВ случаях использования двойной кавычки дважды '' является правильным способом различения элемента синтаксиса и строкового литерала.

Что касается причины:

  • the *Синтаксис 1011 * - это не SQL, а расширение команды HANA.Таким образом, не существует общего стандарта, который нарушает текущая реализация.

  • , в котором дано, это расширение команды врезано в, соответственно ограничено стандартным синтаксисом SQL и имеетбыть обработанным тем же парсером.

Но параметры анализируются не только один раз анализатором SQL, но и компонентом, который создает сценарий расчета на основе представления расчета.Немного посмотрев, нетрудно понять, что интерфейс параметров - это общий интерфейс ключ-значение, который позволяет передавать все виды информации в calc.engine.

Можно утверждать, что весь подход к предоставлению параметров с помощью пар ключ-значение не согласуется с подходом общего синтаксиса SQL и является правильным.С другой стороны, этот подход обеспечивает общую гибкость для добавления новых элементов команд в части, специфичные для HANA, без структурного изменения синтаксиса (а вместе с ним и синтаксического анализатора).Очевидным недостатком этого является то, что как имена ключей, так и значения имеют строковый тип.Чтобы избежать потери необходимого экранирования для «внутренней строки», необходимо использовать escape-строку, отличную от основной escape-строки SQL.

И здесь мы имеем два разных способа передачи строкового значения, которое будет использоваться в качестве условия фильтра.

Достаточно забавно, но оба подхода могут привести к одному и тому же плану выполнения запроса.

На самом деле, во многих сценариях с входными параметрами строковое значение будет внутренне преобразовано в форму, соответствующую SQL.Это тот случай, когда входной параметр используется для фильтрации или в выражениях в calc.посмотреть, что может быть преобразовано в выражения SQL.

Например, 

 SELECT
     "AAA" 
FROM "_SYS_BIC"."sp/ESC"
     ('PLACEHOLDER' = ('$$IP_TEST$$',  'this is a test\''s test'));

показывает следующий план выполнения в моей системе 

OPERATOR_NAME   OPERATOR_DETAILS
PROJECT         TEST.AAA
  COLUMN TABLE  FILTER CONDITION: TEST.AAA = 'this is a test's test' 
                (DETAIL: ([SCAN] TEST.AAA = 'this is a test's test'))

Обратите внимание, как был удален escape- \'.

В целом: при использовании значений PLACEHOLDER необходимо использовать экранирование \', а во всех других случаях экранирование ''.Это не должно быть очень сложно реализовать для построителя запросов, поскольку вы можете учитывать это при работе с синтаксисом PLACEHOLDER.

...