主页 / user-79909

BigSmoke's questions

Martin Hope
BigSmoke
Asked: 2023-01-08 06:27:30 +0800 CST
  • 5

我见过一些 PostgreSQL 扩展示例，它们使用该.control文件为扩展设置提供默认值。这似乎是必须在文件中提供扩展设置以使它们对 Postgres 有效的时代的遗留问题.control。我的问题是：将扩展设置放入.control文件是否曾经是必需或推荐的做法？

pg_extension我在当前或目录中没有看到任何pg_available_extension_versions建议这种做法的内容。

编辑 2022-01-08：我的问题不够清楚。我在上面专门讨论了运行时配置设置（例如可以通过current_setting()和设置和获取set_config()）。我不是指control file parameters，它们在官方文档中有清楚的描述。

postgresql
Martin Hope
BigSmoke
Asked: 2022-11-23 03:10:11 +0800 CST
  • 5

在我开始将我在项目之间共享的一些 PostgreSQL 代码从迁移转换为适当的扩展之前，我以某种方式确信设置 Postgres 将在每个集群.control中查找扩展文件的路径是可行的。但是，我现在担心，在我的起飞前检查期间，我可能会混淆( retrievable via )。dynamic_libray_pathSHAREDIRpg_config --sharedir

我指望（类似的东西）dynamic_library_path也为扩展工作，因为没有我可以添加自定义位置的路径：

  1. 从 CI 部署安装扩展有点困难，因为它需要更复杂的权限设置；和
  2. 如果我的所有postgres集群/进程都必须共享相同的SHAREDIR.

回顾一下我到目前为止所知道的（防止人们只是将官方文档复制给我）：

  • dynamic_libray_path 可以包含$libdir引用的条目，pg_config --pkglibdir但也可以包含自定义条目。
  • 然而，该文档仅在“动态可加载模块[s]”的上下文中提到了dynamic_libray_pathGUC 。
  • 与CREATE FUNCTIONand不同LOAD，CREATE EXTENSION不允许指定路径，无论是绝对路径还是相对路径。
  • 该CREATE EXTENSION文档明确指出：

    PostgreSQL 将使用文件中的详细信息创建扩展SHAREDIR/extension/extension_name.control。

  • 文档的第 38.17.1 节反映了这一点：

    每个扩展 [...] 的 [] 控制文件必须放在安装SHAREDIR/extension目录中。

  • 在扩展.control文件中，directory 可以进行设置，以便从另一个位置检索扩展.sql的文件。（默认是前面提到的。）SHAREDIR/extension
  • 我遇到了 Craig Ringer 的 2020 邮件列表消息：“RFC: extension_search_pathto supplement dynamic_library_path”，这也向我暗示，至少在当时，扩展没有这样的自定义路径机制。
    • 可悲的是，该消息似乎没有任何后续行动。

我不介意必须从postgres一些类似于的自定义环境变量开始，$PGDATA即使这意味着我必须绕过操作系统出色的默认集群配置和systemd结构。

如果事实证明我真的无法控制每个postgres集群的扩展文件位置，我可能会尝试使用类似mergerfs的方法将已部署的扩展目录中的文件覆盖到上面"$(pg_config --sharedir)/extension"，以便包管理器可以继续将系统范围的扩展写入“降低”，原版SHAREDIR。

postgresql
Martin Hope
BigSmoke
Asked: 2022-11-21 04:21:20 +0800 CST
  • 5

PostgreSQL 中有没有办法检查当前上下文是否在CREATE EXTENSION或期间ALTER EXTENSION … UPDATE？

我正在将我使用自制的 PostgreSQL 迁移框架管理的一些模式切换为基于扩展。在我的迁移框架中，我有多种方式来查看我是否在迁移中运行，并且我希望在扩展安装/升级期间看到类似的东西。

也许我必须抛出并捕获异常并检查堆栈？我希望不是…

上下文 [22 年 11 月 21 日添加]：我想创建一个事件触发器来忽略属于扩展安装和升级的一部分的事件。老实说，我真的不需要这个。（我意识到，在我的用例中，扩展安装无论如何都是从迁移中处理的。）但是，作为一个理论练习，我仍然想知道这是否可能。

postgresql
Martin Hope
BigSmoke
Asked: 2022-04-25 01:33:08 +0800 CST
  • 14

我正在研究一个广泛使用UUIDs的数据库设计PRIMARY KEY。然而，这让我面临一个非常重要的选择。如何命名这些列？我会称它们为uuid，除了UUID作为标识符，我必须在任何地方引用字段名称：

CREATE TABLE thingie (
  "uuid" UUID PRIMARY KEY DEFAULT public.gen_random.uuid(),
  foo VARCHAR,
  bar VARCHAR,
);

一个直接的替代方法似乎是改为调用这些列id：

CREATE TABLE thingie (
  id UUID PRIMARY KEY DEFAULT public.gen_random.uuid(),
  foo VARCHAR,
  bar VARCHAR,
);

这样一来，我就没有列名，从语义上我可以争辩说 UUID 确实是一种 ID；在维恩图中，UUID 圆圈将完全放在 ID 圆圈中。

然而，我（我相信还有很多其他人）已经习惯于id与自动递增INTEGER列关联，以至于我害怕通过调用这些 ID 来打破某种潜规则id。

如果你能用一些坚实的自行车脱落来消除我的困惑，我将非常感激。事实上，我的问题是：你会如何调用你的UUID-typed 代理键，为什么？

postgresql naming-convention