在 Postgres 9.4 中，我试图提取UNIQUEPostgres 中给定表的约束中涉及的所有列的名称。
看起来此类列的名称包含在pg_constraint. 根据文档，与我的问题相关的列称为conkey，它恰好是一个ints数组。
关键是，我提出的查询给了我错误的结果，我很确定这是因为我conkey以错误的方式加入。查询如下：
SELECT
pg_attribute.attname,
pg_constraint.*
FROM
pg_attribute
INNER JOIN pg_constraint
ON pg_attribute.attnum = ANY (pg_constraint.conkey)
WHERE pg_constraint.conrelid = (
SELECT
oid
FROM
pg_class
WHERE
relname LIKE 'test_table'
)
AND pg_constraint.contype = 'u'; -- to filter out non-unique constraints
这是一个用于快速重现的表 DDL：
CREATE TABLE "test_table" (
"date" date DEFAULT now() NOT NULL,
"foo" varchar COLLATE "default" NOT NULL
CONSTRAINT "test_table_foo_key" UNIQUE ("foo")
) …这是我第一次（我认为）有机会使用该hstore数据类型，但我想听听更有经验的人的意见，看看我的想法实际上是个好主意。
现在，我们在这个 Web 应用程序中以 XML 文件的形式导入工资数据，它看起来大致像这个简化版本：
<Company>
<Employee>
<LastName>Smith</LastName>
<FirstName>John</LastName>
<HourlyWage>9999.99</HourlyWage>
<!-- several other hundreds of tags -->
</Employee>
<Employee>
<!-- ... -->
</Employee>
</Company>
每个员工都携带着极其详细的信息，当我说“其他数百个标签”时，是因为它们通常在 800 个到 1400 个以上之间。而且这是每个月的。除了一组核心标签之外，每个员工都可以有不同的组合，因此我上面给出的数字非常波动但非常现实。
现在，部分数据是通过一个漫长、缓慢且非常复杂的过程导入的，而且我观察到，随着频率的增加，我们发现自己说“天哪，如果我们总是导入那个特定标签就好了！ ”。
虽然导入过程是高度可配置的，但仅针对一小部分数据运行它是缓慢的、不切实际的并且非常痛苦。从现在开始，添加导入假设的新标签所需的任何自定义操作要容易得多，但是对于构建历史数据（就像我们总是导入它一样），它很混乱且容易出错。
作为额外的好处，这项任务总是落在这两个人身上，而我就是其中之一，我很想让我们的生活变得更简单。
这就是为什么我正在考虑编写一个快速工具，在夜间打开这些 XML 文件，并为每个月和每个员工创建一个记录，其中包含包含hstore该月所有员工标签的列。
作为 的绝对初学者hstore，这在我看来是一个非常好的用例，特别是如果我们考虑到：
由于每个员工的标签可能不同，因此这本质上是无模式数据。
将标签存储为 EAV（每个标签一行）对于一家拥有 200 名员工的公司来说意味着每月大约 24 万行（每年 280 万行）。当然，没有什么可担心的，但顾客并不只有一个。其中一家拥有超过 7,000 名员工（每年将有 1 亿条记录）。
这些数据只需要被读取，而无需更改。另外，无论如何，它甚至不会被经常阅读。
我真的不关心或不知道任何给定标签的含义。我只是想存储它以供将来使用，告诉我需要哪一个是领域专家的工作。再次强调无模式。
我要设计的表格看起来有点像这样：
- id bigserial
- user_id
- file_timestamp (it's embedded on the name of the …