【问题标题】:Pass an array of integers in array of parameters在参数数组中传递整数数组
【发布时间】:2016-08-18 19:05:48
【问题描述】:

我正在尝试按照pg-promise docs 中的建议在 pg-promise 的参数数组中传递参数数组。

db.any("SELECT fieldname FROM table WHERE fieldname = $1 AND fieldname2 IN ($2)",
        [1,[[1730442],[1695256]],[487413],[454336]]])
    .then(function (data) {
        console.log("DATA:", data); // print data;
    })
    .catch(); 

但它不起作用,我在参数列表后返回了“缺少 )”错误。 或者“运算符不存在:integer = integer[]]”错误,如果我将参数替换为:

[1,[1730442]]

当然,如果我像这样通过它,它会起作用:

[1,1730442]

当涉及到其他参数时,传递值数组是否正确?

我还尝试删除 $2 周围的括号,但没有成功。

【问题讨论】:

  • 在您的示例中,您没有将整数数组作为参数传递,它是整数数组的数组。你真正想要哪一个?

标签: javascript pg-promise


【解决方案1】:

我是pg-promise的作者。


你的例子有些混乱......

您在查询中只使用了两个变量,但传入了四个值:

  • 1
  • [[1730442],[1695256]]
  • [487413]
  • [454336]

而且您的语法不是有效的 JavaScript,因为您最终使用的是 ] 而没有匹配的开头,因此很难理解您要传递的到底是什么。

那么为什么还要将所有值都包装在数组中呢?我相信这只是您想要在 IN() 语句中的整数列表。

当您想在WHERE IN() 中使用值时,它实际上并不是您要传入的那些值的数组,而是一个逗号分隔的值列表。

如果您将示例更改为以下内容:

db.any('SELECT fieldname FROM table WHERE fieldname = $1 AND fieldname2 IN ($2:csv)',
[1, [1730442,1695256,487413,454336]])

您将获得正确的注入值列表。

另见:

【讨论】:

  • 感谢您的详尽回答。第三个 ] 只是因为我同时传递了一个整数和一个整数数组。我没有注意到文档中的 ($2:csv) 符号。
  • @Stanislasdrg 它位于WHERE col IN exampleformat API 中;)
  • 刚刚测试过,它可以工作。再次感谢您的帮助和这个精彩的图书馆。
【解决方案2】:

另一种可能是:

db.any("SELECT fieldname FROM table WHERE fieldname = $1 AND fieldname2 = any ($2)",
        [1,[1730442,1695256,487413,454336]])
    .then(function (data) {
        console.log("DATA:", data); // print data;
    })
    .catch(); 

此处来自 postgresql 手册:https://www.postgresql.org/docs/9.5/static/functions-comparisons.html

右边是一个带括号的表达式,它必须产生一个 数组值。左边的表达式被评估并与 使用给定运算符的数组的每个元素,它必须产生一个 布尔结果。如果任何真结果为“真”,则 ANY 的结果为“真” 获得。如果没有找到真正的结果(包括 数组元素为零的情况)。

如果数组表达式产生一个空数组,ANY 的结果将是 空值。如果左边的表达式产生 null,则 ANY 的结果是 通常为 null(尽管非严格的比较运算符可以 可能会产生不同的结果)。此外,如果右手边的数组 包含任何空元素并且没有获得真正的比较结果, ANY 的结果将为空,而不是假(再次,假设严格 比较运算符)。这符合SQL的正常规则 用于空值的布尔组合。

SOME 是 ANY 的同义词。

【讨论】:

  • 我觉得你刚刚将我的 SQL 技能提升了一个层次。我很好奇您是否对使用这种方法的性能问题有任何经验?您认为这通常更高效 - 因为它可以成为准备好的语句 - 还是与 IN 形式相提并论?其他?
  • 回答了我自己的问题 - 与 8.2 相同:In existing releases, the form with IN (list-of-scalar-constants) can be optimized into indexscan(s), but = ANY (array) isn't. 8.2 will treat them equivalently (in fact, it converts IN (...) to = ANY (ARRAY[...]) !). So depending on your time horizon, you might wish to stick with whichever is cleaner for your calling code. regards, tom lane From postgresql.org/message-id/5373.1158351561%40sss.pgh.pa.us
猜你喜欢
  • 1970-01-01
  • 2023-03-24
  • 1970-01-01
  • 2013-09-18
  • 2018-07-26
  • 2022-08-03
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多