标签: operator

考虑一下SO 上的这个答案，它使询问者对<>运营商感到放心：

<>是 ... 与 相同!=。

但随后一位评论者插嘴说：

确实，它们在功能上是相同的。但是，SQL 优化器如何使用它们是非常不同的。=/!= 被简单地评估为真/假，而 <> 意味着引擎必须查看该值是大于还是小于，这意味着更多的性能开销。只是在编写可能很昂贵的查询时需要考虑的事情。

我相信这是错误的，但为了解决潜在的怀疑论者，我想知道是否有人可以提供权威或规范的来源来证明这些运算符不仅在功能上相同，而且在所有方面都相同？

我有一个表，persons它包含两列，一个id和一个基于 JSONB 的data列（这个表只是为了演示目的而制作的，以使用 PostgreSQL 的 JSON 支持）。

现在，假设它包含两条记录：

1, { name: 'John', age: 30 }
2, { name: 'Jane', age: 20 }

现在，假设我想得到每个 25 岁以上的人的名字。我尝试过的是：

select data->'name' as name from persons where data->'age' > 25

不幸的是，这会导致错误。我可以通过使用->>代替来解决它->，但是比较不再按预期工作，因为不是比较数字，而是比较它们作为字符串的表示：

select data->'name' as name from persons where data->>'age' > '25'

然后我发现我实际上可以通过使用->和强制转换来解决这个问题int：

select data->'name' as name from persons where cast(data->'age' as int) > 25

这有效，但我必须知道实际类型并不是那么好（ageJSON 文档中的类型是number无论如何，那么为什么 PostgreSQL …

该EXCEPT运营商已在SQL Server 2005中引入的，但之间有什么区别NOT IN和EXCEPT？

它也这样做吗？我想用一个例子做一个简单的解释。

我有下面给出的 SQL 查询，我想使用like运算符选择多个值。

我的查询正确吗？

SELECT top 1 employee_id, employee_ident, utc_dt, rx_dt 
FROM       employee
INNER JOIN employee_mdata_history 
ON         employee.ident=employee_mdata_history.employee_ident 
WHERE      employee_id like 'emp1%' , 'emp3%' 
ORDER BY   rx_dt desc

如果没有，有人可以纠正我吗？

我的表有大量以'emp1'和开头的数据'emp3'。我可以根据前 3 个“emp1”和前 2 个“emp3”过滤结果rx_dt吗？

我正在阅读有关物化视图的Postgres 文档，在一个示例中，他们使用以下内容：

SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10;

我试图在我自己的数据库上运行类似的查询，但出现错误。

[42883] ERROR: operator does not exist: character varying <-> unknown

我（可能）不需要使用运算符，但我只是好奇它的作用。

注意事项：

• 我正在运行与文档相同的版本（9.3）
• 我确实尝试过谷歌搜索这个问题，但<->即使你用引号将它括起来，谷歌也会忽略它。

我试图回答这个问题，说明 from 子句是可选的。

如您所见，查询计划中有 BMK 运算符，但没有指示显示它是如何计算的。

到目前为止
我尝试过的步骤：我开始使用 BMK1000 进行搜索，但它显示了一堆使用相同运算符的问题。最后我找到了一个线程，上面写着“您所引用的 BMK 是堆中的存储位置，被保留使用非聚集索引而不是簇键。”..但不确定这与我有什么关系，因为我没有任何索引..

问：
什么是 BMK 运算符以及它是如何计算的。任何指针也会有所帮助

这是重现问题的SQLFiddle

我有一个相当复杂的 Postgres 数据库，其中许多 UUID 字段被错误地存储为 VARCHAR。我想逐步迁移它们，但不幸的是，这样做打破了我的所有观点，因为 Postgres 没有内置的varchar = uuid. 而是重写我的所有视图或尝试一次大规模迁移，我想临时创建一个 uuid = varchar 运算符，直到迁移完成。

我以前从未创建过自定义运算符，并且我在下面的尝试不起作用：

CREATE OR REPLACE FUNCTION uuid_equal_varchar (varchar, uuid)
RETURNS boolean AS 'SELECT $1::text = $2::text;' LANGUAGE sql IMMUTABLE;

CREATE OPERATOR = (
    leftarg = character varying,
    rightarg = uuid,
    procedure = uuid_equal_varchar,
    commutator = =
);

然而，这个运营商打破了一切。包括一个简单的 varchar = varchar 比较（见下文）：

SELECT * FROM test WHERE pk_test = '123';
ERROR:  invalid input syntax for uuid: "123"

有人可以向我解释我做错了什么吗？我是否试图尝试不可能的事情？

我想建立PostgreSQL中的自定义相等操作符，可以在使用GROUP BY，UNION并DISTINCT [ON]为json类型（只是为了好奇的缘故，而不是真实世界中的实现-这就是为什么即将到来的jsonb类型是不是我要找的）。

我可以编写一个函数来测试json相等性：

CREATE OR REPLACE FUNCTION json_equals(json, json)
  RETURNS BOOLEAN
  LANGUAGE sql
  IMMUTABLE
  STRICT
AS $function$
  SELECT CASE f1
    WHEN '{' THEN -- object
      CASE f2
        WHEN '{' THEN (
          SELECT COALESCE(bool_and(k1 IS NOT NULL AND k2 IS NOT NULL AND json_equals(v1, v2)), TRUE)
          FROM (SELECT DISTINCT ON (k1) * FROM json_each($1) AS j1(k1, v1) ORDER BY k1, row_number() OVER () DESC) AS j1
          FULL JOIN …

当有人这样做时，我正在我们的一台测试服务器上运行跟踪：

我可以在跟踪中捕获的查询之一是：

declare @UserOption int
select @UserOption=convert(int, c.value) from sys.configurations c where c.name='user options'

SELECT
CAST(@UserOption & 1 AS bit) AS [DisableDefaultConstraintCheck],
CAST(@UserOption & 2 AS bit) AS [ImplicitTransactions],
CAST(@UserOption & 4 AS bit) AS [CursorCloseOnCommit],
CAST(@UserOption & 8 AS bit) AS [AnsiWarnings],
CAST(@UserOption & 16 AS bit) AS [AnsiPadding],
CAST(@UserOption & 32 AS bit) AS [AnsiNulls],
CAST(@UserOption & 64 AS bit) AS [AbortOnArithmeticErrors],
CAST(@UserOption & 128 AS bit) AS [IgnoreArithmeticErrors],
CAST(@UserOption & 256 AS bit) AS [QuotedIdentifier],
CAST(@UserOption & …

我想知道斜线|/在做什么，

SET equal_area_radius = |/area/pi();

该语句有效，它肯定会更改值：

SELECT |/125.555/pi(); --  returns: 6.32181918120139
SELECT 125.555/pi();   --  returns: 39.9653977598058

斜线运算符有|/什么作用？