On Fri, February 7, 2014 00:47, Andrew Dunstan wrote:
>
> Attached are updated patches.
>
> jsonb-10.patch.gz
> nested-hstore-10.patch.gz
Small changes to json documentation, mostly of typo caliber.
Thanks,
Erik Rijkers
--- doc/src/sgml/datatype.sgml.orig 2014-02-09 14:27:55.264512678 +0100
+++ doc/src/sgml/datatype.sgml 2014-02-09 14:36:47.758675826 +0100
@@ -4254,8 +4254,8 @@
There are two JSON data types: <type>json</type> and <type>jsonb</type>.
Both accept identical sets of values as input. The difference is primarily
a matter of efficiency. The <type>json</type> data type stores an exact
- copy of the the input text, and the processing functions have to reparse
- it to precess it, while the <type>jsonb</type> is stored in a decomposed
+ copy of the input text, and the processing functions have to reparse
+ it to process it, while the <type>jsonb</type> is stored in a decomposed
form that makes it slightly less efficient to input but very much faster
to process, since it never needs reparsing.
</para>
@@ -4275,7 +4275,7 @@
<para>
In general, most applications will find it advantageous to store JSON data
- as <type>jsonb</type>, unless they have quite specialised needs.
+ as <type>jsonb</type>, unless they have quite specialized needs.
</para>
<para>
--- doc/src/sgml/func.sgml.orig 2014-02-09 14:28:12.888989051 +0100
+++ doc/src/sgml/func.sgml 2014-02-09 15:15:44.378580545 +0100
@@ -10157,13 +10157,8 @@
<entry>
Builds a heterogeneously-typed json array out of a variadic argument list.
</entry>
- <entry><literal>SELECT json_build_array(1,2,'3',4,5);</literal></entry>
- <entry>
-<programlisting>
- json_build_array
--------------------
- [1, 2, "3", 4, 5]
- </programlisting>
+ <entry><literal>json_build_array(1,2,'3',4,5);</literal></entry>
+ <entry><literal> [1, 2, "3", 4, 5]</literal>
</entry>
</row>
<row>
@@ -10177,12 +10172,7 @@
constructed out of alternating name/value arguments.
</entry>
<entry><literal>SELECT json_build_object('foo',1,'bar',2);</literal></entry>
- <entry>
-<programlisting>
- json_build_object
-------------------------
- {"foo" : 1, "bar" : 2}
- </programlisting>
+ <entry><literal>{"foo" : 1, "bar" : 2}</literal>
</entry>
</row>
<row>
@@ -10197,7 +10187,7 @@
such that each inner array has exactly two elements, which
are taken as a name/value pair.
</entry>
- <entry><literal>select * from json_object('{a, 1, b, "def", c, 3.5}') or <literal>select json_object('{{a, 1},{b, "def"},{c, 3.5}}')</literal></literal></entry>
+ <entry><literal>SELECT * FROM json_object('{a, 1, b, "def", c, 3.5}') or <literal>select json_object('{{a, 1},{b, "def"},{c, 3.5}}')</literal></literal></entry>
<entry>
<programlisting>
json_object
@@ -10215,13 +10205,8 @@
The two-argument form of JSON object takes keys and values pairwise from two separate
arrays. In all other respects it is identical to the one-argument form.
</entry>
- <entry><literal>select json_object('{a, b}', '{1,2}');</literal></entry>
- <entry>
-<programlisting>
- json_object
-------------------------
- {"a" : "1", "b" : "2"}
- </programlisting>
+ <entry><literal>json_object('{a, b}', '{1,2}');</literal></entry>
+ <entry><literal>{"a" : "1", "b" : "2"}</literal>
</entry>
</row>
</tbody>
@@ -10419,12 +10404,12 @@
<entry><type>anyelement</type></entry>
<entry>
Expands the object in <replaceable>from_json</replaceable> to a row whose columns match
- the record type defined by base. Conversion will be best
+ the record type defined by <parameter>base</parameter>. Conversion will be best
effort; columns in base with no corresponding key in <replaceable>from_json</replaceable>
will be left null. When processing <type>json</type>, if a column is
specified more than once, the last value is used.
</entry>
- <entry><literal>select * from json_populate_record(null::x, '{"a":1,"b":2}')</literal></entry>
+ <entry><literal>SELECT * FROM json_populate_record(null::x, '{"a":1,"b":2}')</literal></entry>
<entry>
<programlisting>
a | b
@@ -10440,13 +10425,13 @@
<entry><type>SETOF anyelement</type></entry>
<entry>
Expands the outermost set of objects in <replaceable>from_json</replaceable> to a set
- whose columns match the record type defined by base.
- Conversion will be best effort; columns in base with no
+ whose columns match the record type defined by <parameter>base</parameter>.
+ Conversion will be best effort; columns in <parameter>base</parameter> with no
corresponding key in <replaceable>from_json</replaceable> will be left null.
When processing <type>json</type>, if a column is specified more
than once, the last value is used.
</entry>
- <entry><literal>select * from json_populate_recordset(null::x, '[{"a":1,"b":2},{"a":3,"b":4}]')</literal></entry>
+ <entry><literal>SELECT * FROM json_populate_recordset(null::x, '[{"a":1,"b":2},{"a":3,"b":4}]')</literal></entry>
<entry>
<programlisting>
a | b
@@ -10521,7 +10506,7 @@
If nested_as_text is true, the function coerces nested complex elements to text.
Also, see notes below on columns and types.
</entry>
- <entry><literal>select * from json_to_record('{"a":1,"b":[1,2,3],"c":"bar"}',true) as x(a int, b text, d text) </literal></entry>
+ <entry><literal>SELECT * FROM json_to_record('{"a":1,"b":[1,2,3],"c":"bar"}',true) as x(a int, b text, d text)</literal></entry>
<entry>
<programlisting>
a | b | d
@@ -10539,9 +10524,9 @@
Returns an arbitrary set of records from a JSON object. As with
json_to_record, the structure of the record must be explicitly defined when making the
call. However, with json_to_recordset the input JSON must be an array containing
- objects. nested_as_text works as with json_to_record.
+ objects. <parameter>nested_as_text</parameter> works as with json_to_record.
</entry>
- <entry><literal>select * from json_to_recordset('[{"a":1,"b":"foo"},{"a":"2","c":"bar"}]',true) as x(a int, b text);</literal></entry>
+ <entry><literal>select * from json_to_recordset('[{"a":1,"b":"foo"},{"a":"2","c":"bar"}]',true) as x(a int, b text)</literal></entry>
<entry>
<programlisting>
a | b
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers