代码之家 › 专栏 › 技术社区 › Adam

在HANA SQL语句的placeholder子句中转义单引号

hana

Adam · 技术社区 · 6 年前

我注意到在placeholder子句的上下文中,“HANA SQL”如何避开单引号存在不一致性。例如,考虑以下占位符子句片段:

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

上面的placeholder子句包含分配给cc_参数的多个值。参数。我们可以看到里面在第二个参数中,我们有一个用反斜杠转义的单引号。但是,我们避开了单引号外部每个论点用另一个单引号(即 '' 而不是 \'' . 可以使用 '' 第一种情况的格式,但不能使用 ’ 第二种情况下的格式。

为什么会有这种差异?它使得在多输入输入参数中转义引号变得困难。我希望以编程方式为HANA创建SQL查询。我是不是错过了什么?使用安全吗 \'' 结束 ’ 在所有情况下?或者,我是否需要能够判断单引号出现在哪里并根据需要进行转义的逻辑?

1 回复 | 直到 6 年前

Adam 6 年前

这里的隐式规则(由软件的实现方式给出)是计算视图的参数值的反斜杠 \ 用于转义单引号。

对于所有出现的标准SQL字符串,使用单引号两次 '' 是区分语法元素和字符串文字的正确方法。

至于为什么:

这个 PLACEHOLDER 语法不是SQL,而是特定于HANA的命令扩展。因此,当前的实现没有违反一般标准。
给定的,此命令扩展名是 嵌入的 into,分别夹在标准的SQL语法上,必须由同一个解析器处理。

但是参数不仅由SQL解析器解析一次,而且由根据计算视图实例化计算场景的组件再次解析。稍微斜视一下,就不难看出参数接口是一个通用的键值接口,它允许将各种信息移交给计算引擎。

有人可能会说,通过键值对提供参数的整个方法与一般的SQL语法方法不一致,并且是正确的。另一方面,这种方法允许在不改变语法(以及语法分析器)的情况下,向HANA特定的部分添加新的命令元素的一般灵活性。这明显的缺点是两个键名以及值都是字符串类型的。为了避免丢失“内部字符串”所需的转义,需要使用与主SQL转义字符串不同的转义字符串。

这里我们有两种不同的方法来传递一个字符串值,作为一个过滤条件。

有趣的是,这两种方法可能仍然会导致相同的查询执行计划。

事实上,在许多使用输入参数的场景中,字符串值将在内部转换为符合SQL的形式。当输入参数用于筛选或在可转换为SQL表达式的Calc.视图中的表达式时,就是这种情况。

例如

 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'))

注意如何逃脱- \' 已删除。

总而言之:使用时 占位符 价值观 \ 需要使用转义,在所有其他情况下, ’ 逃逸。对于查询生成器来说,实现这一点并不十分困难,因为在处理 占位符 语法。