PostgreSQL 9.2中将引入生成JSON数据功能

红薯
 红薯
发布于 2012年01月17日
收藏 4

PostgreSQL开发者Andrew Dunstan写到

上周三,也就是PostgreSQL 9.2最后一个commitfest到来的前四天,Robert Haas提交了一个名为JSON for 9.2的 补丁,欲将JSON列为PostgreSQL的核心类型。基本上,该补丁功能是对文本进行解析,确保它是有效的JSON数据,并加以存储。这个功能我原本 打算在9.2版本中放弃的,不过我考虑了下发现Robert的补丁太小了点,因此决定继续并又添加了一些功能,包括:query_to_json()、 array_to_json()以及record_to_json(),完成了从ProstgreSQL生成JSON数据。

以下是来自回归测试中的一些简单示例:

SELECT query_to_json('select x as b, x * 2 as c from generate_series(1,3) x',false);
                query_to_json               
---------------------------------------------
 [{"b":1,"c":2},{"b":2,"c":4},{"b":3,"c":6}]
(1 row)

SELECT array_to_json('{{1,5},{99,100}}'::int[]);
  array_to_json  
------------------
 [[1,5],[99,100]]
(1 row)

-- row_to_json
SELECT row_to_json(row(1,'foo'));
     row_to_json    
---------------------
 {"f1":1,"f2":"foo"}
(1 row)

更简单一点的:

SELECT row_to_json(q)
FROM (SELECT $$a$$ || x AS b,
         y AS c,
         ARRAY[ROW(x.*,ARRAY[1,2,3]),
               ROW(y.*,ARRAY[4,5,6])] AS z
      FROM generate_series(1,2) x,
           generate_series(4,5) y) q;
                            row_to_json                            
--------------------------------------------------------------------
 {"b":"a1","c":4,"z":[{"f1":1,"f2":[1,2,3]},{"f1":4,"f2":[4,5,6]}]}
 {"b":"a1","c":5,"z":[{"f1":1,"f2":[1,2,3]},{"f1":5,"f2":[4,5,6]}]}
 {"b":"a2","c":4,"z":[{"f1":2,"f2":[1,2,3]},{"f1":4,"f2":[4,5,6]}]}
 {"b":"a2","c":5,"z":[{"f1":2,"f2":[1,2,3]},{"f1":5,"f2":[4,5,6]}]}
(4 rows)

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 OSCHINA 社区 [http://www.oschina.net]
本文标题:PostgreSQL 9.2中将引入生成JSON数据功能
加载中

最新评论(16

mark35
mark35

引用来自“宏哥”的评论

引用来自“mark35”的评论

引用来自“宏哥”的评论

引用来自“mark35”的评论

引用来自“宏哥”的评论

引用来自“mark35”的评论

发现9.2的一个强劲新功能:

COUNT(*)
.... With MVCC capable databases, caching the COUNT(*) would result in incorrect data being returned. PostgreSQL 9.2 will have index-only scan support which uses the visibility map feature to determine whether a row is visible to the current transaction rather than visiting the page. This means dramatically faster COUNT(*) results. PostgreSQL 9.2 index-only scans PostgreSQL Slow Count() Workaround InnoDB COUNT(*)

http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL#COUNT.28.2A.29

相关: http://www.depesz.com/2011/10/08/waiting-for-9-2-index-only-scans/

有了index-only scans功能那pgsql执行COUNT(*)的效率将会极大提升!!

不错,我现在实际环境当中用,已经非常快了.不知道pg9.2啥时候正式发布

大概4月份出beta,正式版可能下半年了。如果pg的COUNT(*)速度上来了,那mysql对比pgsql将毫无优势可言。

其实我到觉得,pgsql的对手是mssql和oracle.

可是国内人只会拿它和mysql相比~~ 真是杀鸡用牛刀……
我觉得pgsql如果支持嵌套事务,并且在表分区上加强(避免手工写触发器重定向INSERT)那与mssql/oracle比较就更有竞争力。

基本上,如果不是系统规模极大,要求极高的,pg真是够用了.

这倒也是。对于超大规模系统,恐怕也首选商业DB了
宏哥
宏哥

引用来自“mark35”的评论

引用来自“宏哥”的评论

引用来自“mark35”的评论

引用来自“宏哥”的评论

引用来自“mark35”的评论

发现9.2的一个强劲新功能:

COUNT(*)
.... With MVCC capable databases, caching the COUNT(*) would result in incorrect data being returned. PostgreSQL 9.2 will have index-only scan support which uses the visibility map feature to determine whether a row is visible to the current transaction rather than visiting the page. This means dramatically faster COUNT(*) results. PostgreSQL 9.2 index-only scans PostgreSQL Slow Count() Workaround InnoDB COUNT(*)

http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL#COUNT.28.2A.29

相关: http://www.depesz.com/2011/10/08/waiting-for-9-2-index-only-scans/

有了index-only scans功能那pgsql执行COUNT(*)的效率将会极大提升!!

不错,我现在实际环境当中用,已经非常快了.不知道pg9.2啥时候正式发布

大概4月份出beta,正式版可能下半年了。如果pg的COUNT(*)速度上来了,那mysql对比pgsql将毫无优势可言。

其实我到觉得,pgsql的对手是mssql和oracle.

可是国内人只会拿它和mysql相比~~ 真是杀鸡用牛刀……
我觉得pgsql如果支持嵌套事务,并且在表分区上加强(避免手工写触发器重定向INSERT)那与mssql/oracle比较就更有竞争力。

基本上,如果不是系统规模极大,要求极高的,pg真是够用了.
mark35
mark35

引用来自“宏哥”的评论

引用来自“mark35”的评论

引用来自“宏哥”的评论

引用来自“mark35”的评论

发现9.2的一个强劲新功能:

COUNT(*)
.... With MVCC capable databases, caching the COUNT(*) would result in incorrect data being returned. PostgreSQL 9.2 will have index-only scan support which uses the visibility map feature to determine whether a row is visible to the current transaction rather than visiting the page. This means dramatically faster COUNT(*) results. PostgreSQL 9.2 index-only scans PostgreSQL Slow Count() Workaround InnoDB COUNT(*)

http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL#COUNT.28.2A.29

相关: http://www.depesz.com/2011/10/08/waiting-for-9-2-index-only-scans/

有了index-only scans功能那pgsql执行COUNT(*)的效率将会极大提升!!

不错,我现在实际环境当中用,已经非常快了.不知道pg9.2啥时候正式发布

大概4月份出beta,正式版可能下半年了。如果pg的COUNT(*)速度上来了,那mysql对比pgsql将毫无优势可言。

其实我到觉得,pgsql的对手是mssql和oracle.

可是国内人只会拿它和mysql相比~~ 真是杀鸡用牛刀……
我觉得pgsql如果支持嵌套事务,并且在表分区上加强(避免手工写触发器重定向INSERT)那与mssql/oracle比较就更有竞争力。
宏哥
宏哥

引用来自“mark35”的评论

引用来自“宏哥”的评论

引用来自“mark35”的评论

发现9.2的一个强劲新功能:

COUNT(*)
.... With MVCC capable databases, caching the COUNT(*) would result in incorrect data being returned. PostgreSQL 9.2 will have index-only scan support which uses the visibility map feature to determine whether a row is visible to the current transaction rather than visiting the page. This means dramatically faster COUNT(*) results. PostgreSQL 9.2 index-only scans PostgreSQL Slow Count() Workaround InnoDB COUNT(*)

http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL#COUNT.28.2A.29

相关: http://www.depesz.com/2011/10/08/waiting-for-9-2-index-only-scans/

有了index-only scans功能那pgsql执行COUNT(*)的效率将会极大提升!!

不错,我现在实际环境当中用,已经非常快了.不知道pg9.2啥时候正式发布

大概4月份出beta,正式版可能下半年了。如果pg的COUNT(*)速度上来了,那mysql对比pgsql将毫无优势可言。

其实我到觉得,pgsql的对手是mssql和oracle.
mark35
mark35

引用来自“宏哥”的评论

引用来自“mark35”的评论

发现9.2的一个强劲新功能:

COUNT(*)
.... With MVCC capable databases, caching the COUNT(*) would result in incorrect data being returned. PostgreSQL 9.2 will have index-only scan support which uses the visibility map feature to determine whether a row is visible to the current transaction rather than visiting the page. This means dramatically faster COUNT(*) results. PostgreSQL 9.2 index-only scans PostgreSQL Slow Count() Workaround InnoDB COUNT(*)

http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL#COUNT.28.2A.29

相关: http://www.depesz.com/2011/10/08/waiting-for-9-2-index-only-scans/

有了index-only scans功能那pgsql执行COUNT(*)的效率将会极大提升!!

不错,我现在实际环境当中用,已经非常快了.不知道pg9.2啥时候正式发布

大概4月份出beta,正式版可能下半年了。如果pg的COUNT(*)速度上来了,那mysql对比pgsql将毫无优势可言。
宏哥
宏哥

引用来自“mark35”的评论

发现9.2的一个强劲新功能:

COUNT(*)
.... With MVCC capable databases, caching the COUNT(*) would result in incorrect data being returned. PostgreSQL 9.2 will have index-only scan support which uses the visibility map feature to determine whether a row is visible to the current transaction rather than visiting the page. This means dramatically faster COUNT(*) results. PostgreSQL 9.2 index-only scans PostgreSQL Slow Count() Workaround InnoDB COUNT(*)

http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL#COUNT.28.2A.29

相关: http://www.depesz.com/2011/10/08/waiting-for-9-2-index-only-scans/

有了index-only scans功能那pgsql执行COUNT(*)的效率将会极大提升!!

不错,我现在实际环境当中用,已经非常快了.不知道pg9.2啥时候正式发布
mark35
mark35
发现9.2的一个强劲新功能:

COUNT(*)
.... With MVCC capable databases, caching the COUNT(*) would result in incorrect data being returned. PostgreSQL 9.2 will have index-only scan support which uses the visibility map feature to determine whether a row is visible to the current transaction rather than visiting the page. This means dramatically faster COUNT(*) results. PostgreSQL 9.2 index-only scans PostgreSQL Slow Count() Workaround InnoDB COUNT(*)

http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL#COUNT.28.2A.29

相关: http://www.depesz.com/2011/10/08/waiting-for-9-2-index-only-scans/

有了index-only scans功能那pgsql执行COUNT(*)的效率将会极大提升!!
ValueError
ValueError

引用来自“宏哥”的评论

引用来自“mark35”的评论

pgsql时刻在进步~

postgresql 可以通过python/PHP嵌入进行无缝的json支持.

用 JSON 来存 schemaless 的数据当然是好想法,可是检索起来没有数据库的原生支持就太纠结了。
宏哥
宏哥

引用来自“mark35”的评论

pgsql时刻在进步~

postgresql 可以通过python/PHP嵌入进行无缝的json支持.
地鼠特工队
地鼠特工队
这个好啊,用node.js操作就更简单了。
返回顶部
顶部