主页 / user-101002

ARX's questions

Martin Hope
ARX
Asked: 2022-12-31 08:39:55 +0800 CST
  • 6

在 Postgres 上，我正在寻找一种方法来唯一标识一个表，而不管名称是否更改。OID 似乎适合于此。但是 OID 在 2^32-1 之后换行。

如果要换行 OID，我可以在 pg_class 上得到两个具有相同 OID 的表吗？或者有什么可以阻止它的吗？

postgresql
Martin Hope
ARX
Asked: 2021-10-03 19:21:13 +0800 CST
  • 10

在 PG 14 的文档中，该CREATE FUNCTION部分的手册说LANGUAGE SQL函数的主体可以是单个语句：

RETURN expression

或一个块：

BEGIN ATOMIC
statement;
statement;
...
statement;
END

没有对该块的语义给出任何解释。这看起来类似于BEGIN ... END;PL/pgSQL 中的块，但似乎有所不同。

写一组语句 inside 或 without 有什么区别BEGIN ATOMIC ... END？什么时候需要使用这样的块？ATOMIC关键字是强制性的吗？

postgresql functions
Martin Hope
ARX
Asked: 2021-09-13 17:18:32 +0800 CST
  • 1

在 PG 13 文档中，有几个用于特殊目的的 ICU 归类示例。还提到存在允许创建排序规则以忽略重音符号的 ICU 语言环境，并且可以在https://github.com/unicode-org/cldr/blob/master/common/bcp47/collat​​ion.xml上找到它们

但是，在阅读了该文档之后，我仍然不清楚应该使用什么语言环境来创建 ICU 排序规则，以便在西班牙语中进行不区分重音的比较。

这种 ICU 语言环境的名称是什么？有没有 ICU 西班牙语排序规则的列表？

postgresql collation
Martin Hope
ARX
Asked: 2021-09-05 08:02:31 +0800 CST
  • 0

我希望将 tsvector 数组的词位放在一列中，每行一个。我可以首先取消嵌套数组，然后使用以下命令生成 tsvector：

SELECT (unnest(unnest(my_array))).lexeme
FROM my_table
WHERE id = 1;

这使：

lexeme  
----------
foo
bar
baz
...

但是，我注意到，如果我尝试在 FROM 子句中做同样的事情：

SELECT lexeme
FROM unnest(
    (SELECT unnest(my_array) FROM my_table WHERE id = 1)
);

我得到：

错误：用作表达式的子查询返回多行

所以，我最终这样做：

SELECT lexeme
FROM (
    SELECT (unnest(col1)).lexeme
    FROM (
        SELECT unnest(my_array) 
        FROM my_table 
        WHERE id = 1 
    ) AS t(col1)
) AS t2;

我得到了原始结果。但这很冗长。所以，我想知道：

  1. 为什么 unnest() 在 FROM 子句中需要单个输入行，但在 SELECT 子句中不需要？

  2. 有没有比我的代码更简洁、不那么复杂的方式来获取 FROM 子句中的词位列？

  3. SELECT 子句中的取消嵌套与 FROM 子句中的取消嵌套在性能上是否存在差异？

postgresql full-text-search
Martin Hope
ARX
Asked: 2016-10-01 10:05:39 +0800 CST
  • 79

以下摘自一本关于 db design 的书（Beginning Database Design ISBN: 0-7645-7490-6）：

使用视图的危险在于过滤针对视图的查询，期望读取非常大的表的一小部分。任何过滤都应该在视图中完成，因为对视图本身的任何过滤都是在视图中的查询完成执行后应用的。视图通常可用于加快开发过程，但从长远来看会完全破坏数据库性能。

以下是 PostgreSQL 9.5 文档的摘录：

自由使用视图是良好 SQL 数据库设计的一个关键方面。视图允许您在一致的接口后面封装表结构的细节，这些细节可能会随着应用程序的发展而改变。

这两个来源似乎相互矛盾（“不要用视图设计”与“用视图做设计”）。

但是，在 PG 中，视图是使用规则系统实现的。因此，可能（这是我的问题）对视图的任何过滤都被重写为视图内的过滤器，从而导致对基础表执行单个查询。

我的解释是否正确并且 PG 将 WHERE 子句组合到视图中和视图之外？还是一个接一个地单独运行它们？任何简短的、独立的、正确的（可编译的）示例？

postgresql optimization