PostgreSQL v9.X有真正的"记录阵列"吗？

Question

此查询工作正常,

 WITH test AS (
   SELECT array_agg(t) as x FROM (
     SELECT 1111 as id, 'aaaaa' as cc  
   ) AS t
 ) SELECT x[1] FROM test;

但是, 我可以访问recod元素吗？ 我试试SELECT x[1].id; SELECT x[1][1]; ......什么都行不通

PS:谷歌我们只看到OLD解决方案......这里的上下文是v9.X,没有关于"记录阵列"的消息？

---

我也试试

 select x[1] from (select array[row(1,2)] as x) as t;

无法仅访问第1项或仅访问第2项的解决方案.

---

我无法遵循的线索:postgresql.1045698.n5.nabble.com使用CREATE TYPE... 解决问题好的,但我需要"所有查询"解决方案.PostgreSQL的"动态打字"在哪里？如何在没有CREATE TYPE条款的情况下进行CAST或表达类型？

Answer 1

目前,除了通过函数调用语法或通过hstore之外,似乎没有任何用于访问匿名类型记录的语法.这是不幸的,但不太可能匆忙修复,除非真正关心的人来实现它.还有其他优先事项.

您有三种解决方法选项:

• CREATE TYPE
• hstore

CREATE TYPE

问题在于匿名类型的记录.所以不要匿名.不幸的是,这只有在它成为匿名记录类型之前才有可能; 您目前无法record转换为usertype.所以你需要这样做:

CREATE TYPE some_t AS (id integer, cc text);

WITH test AS (
   SELECT array_agg(t::some_t) as x FROM (
     SELECT 1111 as id, 'aaaaa' as cc  
   ) AS t
 ) SELECT x[1].id FROM test;

请注意some_t在聚合之前将子查询输出转换为.

我不能说我理解为什么在索引数组之后无法执行此强制转换.

hstore

像往常一样,hstore乘坐困难类型的问题大多是救援.

regress=> WITH test AS (
       SELECT array_agg(t) as x FROM (
         SELECT 1111 as id,  'aaaaa' as cc  
       ) AS t
     ) SELECT hstore(x[1])->'id' FROM test;
 ?column? 
----------
 1111
(1 row)

你需要hstore扩展,我确信它效率不高,但它确实有效.这建立在对hstore匿名记录创建hstore 的支持的基础上,这些记录已添加到支持NEW和OLD触发器中,这是一个过去的痛点.

包装功能？

事实证明,使用简单的包装函数无法绕过它,让您在调用站点上指定类型:

regress=> CREATE OR REPLACE FUNCTION identity(record) RETURNS record AS $$
          SELECT $1; 
          $$ LANGUAGE sql IMMUTABLE;
ERROR:  SQL functions cannot have arguments of type record

所以你必须使用更高开销的过程语言,此时你不妨使用hstore,它会更快更容易.

让它变得更好？

所以,这有点难看.永远不可能直接从匿名记录索引字段,因为它可能不存在并且无法推断其类型.但是我们没有理由不能使用允许我们record从函数返回并在调用者端指定其类型的类型系统功能,以便在强制转换中也这样做.

应该可以使PostgreSQL支持如下:

WITH test AS (
   SELECT array_agg(t) as x FROM (
      SELECT 1111 as id,  'aaaaa' as cc  
   ) AS t
) SELECT (x[1] AS some_t(id integer, cc text)).id  FROM test;

它只涉及适当的解析器黑客攻击,以及一种确保在与列别名冲突时不会被模糊解析的方法.

实际上,如果有人愿意投入工作并说服团队相当大量的查询计划器处理器所需的时间是值得的,那么即使是类型推断也是可能的.(不太可能).

这是类型系统中一个令人恼火的,但很小的角落.如果你想改变它,你需要在pgsql-general上发出噪音,并伴随着这种噪音,愿意做真正的工作来改善问题.这可能涉及学习比你想知道的更多关于PostgreSQL类型系统内部的知识,学习"向后兼容性"的乐趣,以及围绕和围绕圈子的令人沮丧的争论.欢迎来到开源!