标签: case-sensitive

我想知道在使用全文搜索时创建一个结合两个函数的索引是否有意义：lower(name)而f_unaccent(name)Wheref_unaccent只是我的包装器，使 unaccent 函数不可变。

我确实有一个正在处理的索引：f_unaccent(name)使用varchar_pattern_ops. 我的问题是：组合lower和unaccent函数的索引是否会被 full_text_search 触发lower(f_unaccent(name))。

我不知道该lower函数是否对全文搜索算法有用。

SQL-92 标准的第 5.6 节包含规则 10...13，其中未加引号的标识符应大写，因此foo变为FOO但"foo"仍然是foo。

例如，Oracle、IBM DB2、Snowflake和ksqlDB遵守这些规则，但Postgres 、MySQL 或 SQLite 则不遵守这些规则。

问题是，为什么？根据我的理解，在具有大量关键字的语言中可选地引用标识符是有意义的。标识符一致的区分大小写或不区分大小写也是有意义的。但让它依赖于被引用的标识符看起来并不合理。

我缺少什么？

我想要 PostgreSQL 数据库中表中的一列（我使用的是 9.6 版）。我知道UTF8_UNICODE_CIMySQL上的排序规则，所以我尝试了：

CREATE TABLE thing (
    id    BIGINT PRIMARY KEY
   ,name  VARCHAR(120) NOT NULL COLLATE "UTF8_UNICODE_CI"
);

但我得到：

ERROR: collation "UTF8_UNICODE_CI" for encoding "UTF8" does not exist

Run Code Online (Sandbox Code Playgroud)

环顾四周，我发现pg_collation表格显示了排序规则，其中显示：

=# SELECT * from pg_collation;
 collname | collnamespace | collowner | collencoding | collcollate | collctype
----------+---------------+-----------+--------------+-------------+-----------
 default  |            11 |        10 |           -1 |             |
 C        |            11 |        10 |           -1 | C           | C
 POSIX    |            11 |        10 |           -1 | …

在 PostgreSQL 9.4 中，具有以下架构：

CREATE TABLE people (
    id INTEGER PRIMARY KEY,
    name TEXT,
    junk CHAR(1000)
);

INSERT INTO people(id, name)
 SELECT generate_series(1,100000), md5(random()::text);

CREATE INDEX ON people (name text_pattern_ops);

如果我按名称搜索，则使用索引：

test=# explain analyze select id, name from people where name like 'a%';
                                                           QUERY PLAN                                                           
--------------------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on people  (cost=248.59..1160.92 rows=6061 width=37) (actual time=2.412..8.340 rows=6271 loops=1)
   Filter: (name ~~ 'a%'::text)
   Heap Blocks: exact=834
   ->  Bitmap Index Scan on people_name_idx  (cost=0.00..247.08 rows=6266 width=0) (actual time=2.123..2.123 rows=6271 loops=1)
         Index Cond: …

在 Microsoft SQL Server (2014) 中，可以在不区分大小写和区分大小写的排序规则之间进行选择。

我使用区分大小写的排序规则的原因是"test" = "TEST"return false。

然而，我想保留的是，当表"TEST"存在时，编写类似的查询select * from test;仍然有效。当数据库有区分大小写的排序规则时，它不会，因为我需要像这样写select * from TEST;

有没有办法分别设置“对象整理”和“字符串整理”？

前言：我指的不是 查询。

SSMS 中有许多允许过滤的地方，例如对象资源管理器和分析器，但这些都将过滤器视为区分大小写，否则没有可见选项，因此如果您搜索，contains 'ASDF'则包括“ASDF_MyEntity”之类的值，但“asdf_MyEntity” "省略。

例如，我们在大型服务器上有很多SQL 代理作业，我正在尝试使用对象资源管理器按项目名称过滤它们，我们总是在作业名称前加上前缀。但是，这些显示为大写和小写变体。

另一个用例是在数千个条目中搜索与模块相关的存储过程。如果命名不一致（例如 PascalCase 与 camelCase），过滤搜索将忽略它。这对于调试来说似乎是一个不必要的幻象危险。

此外，对象资源管理器中的排序将每种类型的实体（例如表名、存储过程、作业名称等）的大写变体放在小写之前（因此大写Z在小写之前a），所以我要么必须滚动很多，或检查两个不同的过滤器（如果不是全部大写或全部小写字母，则检查更多过滤器 -准确地说是2 ^len(name)次）。

我意识到我只能手动查询作业、表和其他实体，但鉴于 SSMS 存在，这样做是荒谬的，因为它的名称是“SQL Server Management Studio”。

我可以做些什么来使 SSMS（和 SQL Server Profiler）像其他所有 Windows 应用程序一样忽略大小写？也许我可以在本地更改排序规则设置？

另外，为什么微软在实施 SSMS 时做出这个决定？我发现它只是有害的。

_{此外，SSMS 的加载初始屏幕显示“基于 Visual Studio 构建”，这会忽略解决方案资源管理器中的大小写。}

PS 使用 SSMS 2014（版本 12.0.5214.6）。我无法进行任何服务器端更改，并且我的本地开发环境应与目标服务器环境匹配以进行测试。