JSON docs: RFC7159 is now superceded

Started by Simon Riggsover 3 years ago4 messages
#1Simon Riggs
simon.riggs@enterprisedb.com
1 attachment(s)

Minor doc patch to replace with latest RFC number

Intended for PG15

--
Simon Riggs http://www.EnterpriseDB.com/

Attachments:

json_docs_rfc8259.v1.patchapplication/octet-stream; name=json_docs_rfc8259.v1.patchDownload
diff --git a/doc/src/sgml/json.sgml b/doc/src/sgml/json.sgml
index c4223fafb6..dfcd025efb 100644
--- a/doc/src/sgml/json.sgml
+++ b/doc/src/sgml/json.sgml
@@ -13,8 +13,9 @@
 
  <para>
   JSON data types are for storing JSON (JavaScript Object Notation)
-  data, as specified in <ulink url="https://tools.ietf.org/html/rfc7159">RFC
-  7159</ulink>. Such data can also be stored as <type>text</type>, but
+  data, as specified in <ulink url="https://tools.ietf.org/html/rfc8259">RFC
+  8259</ulink>, which supercedes the earlier <acronym>RFC</acronym> 7159.
+  Such data can also be stored as <type>text</type>, but
   the JSON data types have the advantage of enforcing that each
   stored value is valid according to the JSON rules.  There are also
   assorted JSON-specific functions and operators available for data stored
@@ -61,7 +62,7 @@
  </para>
 
  <para>
-  <acronym>RFC</acronym> 7159 specifies that JSON strings should be encoded in UTF8.
+  <acronym>RFC</acronym> 8259 specifies that JSON strings should be encoded in UTF8.
   It is therefore not possible for the JSON
   types to conform rigidly to the JSON specification unless the database
   encoding is UTF8. Attempts to directly include characters that
@@ -71,7 +72,7 @@
  </para>
 
  <para>
-  <acronym>RFC</acronym> 7159 permits JSON strings to contain Unicode escape sequences
+  <acronym>RFC</acronym> 8259 permits JSON strings to contain Unicode escape sequences
   denoted by <literal>\u<replaceable>XXXX</replaceable></literal>.  In the input
   function for the <type>json</type> type, Unicode escapes are allowed
   regardless of the database encoding, and are checked only for syntactic
@@ -103,7 +104,7 @@
 
  <para>
   When converting textual JSON input into <type>jsonb</type>, the primitive
-  types described by <acronym>RFC</acronym> 7159 are effectively mapped onto
+  types described by <acronym>RFC</acronym> 8259 are effectively mapped onto
   native <productname>PostgreSQL</productname> types, as shown
   in <xref linkend="json-type-mapping-table"/>.
   Therefore, there are some minor additional constraints on what
@@ -113,11 +114,11 @@
   Notably, <type>jsonb</type> will reject numbers that are outside the
   range of the <productname>PostgreSQL</productname> <type>numeric</type> data
   type, while <type>json</type> will not.  Such implementation-defined
-  restrictions are permitted by <acronym>RFC</acronym> 7159.  However, in
+  restrictions are permitted by <acronym>RFC</acronym> 8259.  However, in
   practice such problems are far more likely to occur in other
   implementations, as it is common to represent JSON's <type>number</type>
   primitive type as IEEE 754 double precision floating point
-  (which <acronym>RFC</acronym> 7159 explicitly anticipates and allows for).
+  (which <acronym>RFC</acronym> 8259 explicitly anticipates and allows for).
   When using JSON as an interchange format with such systems, the danger
   of losing numeric precision compared to data originally stored
   by <productname>PostgreSQL</productname> should be considered.
@@ -172,7 +173,7 @@
   <title>JSON Input and Output Syntax</title>
   <para>
    The input/output syntax for the JSON data types is as specified in
-   <acronym>RFC</acronym> 7159.
+   <acronym>RFC</acronym> 8259.
   </para>
   <para>
    The following are all valid <type>json</type> (or <type>jsonb</type>) expressions:
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Simon Riggs (#1)
Re: JSON docs: RFC7159 is now superceded

Simon Riggs <simon.riggs@enterprisedb.com> writes:

Minor doc patch to replace with latest RFC number

Hmm, I'm a bit disinclined to claim compliance with a new RFC
sight unseen. What were the changes?

regards, tom lane

#3Simon Riggs
simon.riggs@enterprisedb.com
In reply to: Tom Lane (#2)
Re: JSON docs: RFC7159 is now superceded

On Wed, 13 Apr 2022 at 14:53, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Simon Riggs <simon.riggs@enterprisedb.com> writes:

Minor doc patch to replace with latest RFC number

Hmm, I'm a bit disinclined to claim compliance with a new RFC
sight unseen. What were the changes?

I checked... so I should have mentioned this before

https://datatracker.ietf.org/doc/html/rfc8259#appendix-A

--
Simon Riggs http://www.EnterpriseDB.com/

#4Andrew Dunstan
andrew@dunslane.net
In reply to: Simon Riggs (#1)
Re: JSON docs: RFC7159 is now superceded

On 2022-04-13 We 09:38, Simon Riggs wrote:

Minor doc patch to replace with latest RFC number

Intended for PG15

Idea is fine, but

-  data, as specified in <ulink
url="https://tools.ietf.org/html/rfc7159">RFC
-  7159</ulink>. Such data can also be stored as <type>text</type>, but
+  data, as specified in <ulink
url="https://tools.ietf.org/html/rfc8259">RFC
+  8259</ulink>, which supercedes the earlier <acronym>RFC</acronym> 7159.
+  Such data can also be stored as <type>text</type>, but

Do we need to mention the obsoleting of RFC7159? Anyone who cares enough
can see that by looking at the RFC - it mentions what it obsoletes.

I haven't checked that anything that changed in RFC8259 affects us. I
doubt it would but I guess we should double check.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com