create table t (a int primary key,b text); insert into t values (1,'value1'); insert into t values (2,'value2'); insert into t values (3,'value3');
我想要类似的东西
[{"a":1,"b":"value1"},{"a":2,"b":"value2"},{"a":3,"b":"value3"}]
要么
{"a":[1,2,3],"b":["value1","value2","value3"]}
(实际上它会更有用知道两者)。我试过一些事情
select row_to_json(row) from (select * from t) row; select array_agg(row) from (select * from t) row; select array_to_string(array_agg(row),'') from (select * from t) row;
我觉得我很近，但不是真的。我应该看看除9.15. JSON Functions and Operators之外的其他文档吗？
顺便说一句，我不知道我的想法。这是通常的设计决策吗？我的想法是，我可以，当然，取上述第一个查询的结果，并在应用程序中服务它之前操作它的客户端，但如果Postgresql可以直接创建最终的JSON对象，它会更简单，因为我还没有包括任何对我的应用程序中的任何JSON库的依赖。
SELECT array_to_json(array_agg(t)) FROM t
结果是以下JSON：
[{"a":1,"b":"value3"}]
这里是一个sqlFiddle：http://sqlfiddle.com/#!15/5860d/11/0.sqlFiddle的结果有一些奇怪的“值”/“类型”事情在一个JSON对象，它转义结果字符串(映射到“值”)，但似乎没有发生当它在普通Postgresql上运行时。它似乎是sqlFiddle的一些怪癖。
至于它是一个好的设计或不是真的取决于你的具体应用。一般来说，基准测试将是最好的方式来告诉这是否适合你的性能。在可维护性方面，我没有看到任何特殊的问题。恰恰相反。它简化了你的应用程序代码，意味着有更少的维护，至少在我看来。如果PG能给你完全满意的结果，我想到的不使用它的唯一原因是性能的考虑。不要重复轮子和所有。
编辑：
我没有意识到你在寻找两个结果的查询。
首先，对于您的第二个结果，您可以使用：
SELECT row_to_json(r)
FROM (SELECT array_agg(t.a) AS a,array_agg(t.b) AS b
FROM t
) r
{"a":[1,"value3"]}
sqlFiddle：http://sqlfiddle.com/#!15/5860d/42/0
第二，在我的挖掘中，我发现了9.3中引入的几个其他功能，你应该考虑：
1)json_agg：这是你想要的第一个结果开箱即用。
SELECT json_agg(t) FROM t
sqlFiddle：http://sqlfiddle.com/#!15/5860d/38/0
2)to_json：这可以用于替换array_to_json或row_to_json，并给出相同的结果。
SELECT to_json(array_agg(t)) FROM t
