Subject: Inclusion of json in list of standard data types

From: Bob Kline <[email-masked]>
Date: Sat, 6 Dec 2025 09:07:17 -0500

Would there be any reason not to add "json" to the list of data types
"specified by SQL" in the "Compatibility" box shown near the beginning
of Chapter 8 ("Data Types") of the PostgreSQL documentation?

-- 
Bob Kline
https://www.rksystems.com
mailto:[email-masked]

---

From: Tom Lane <[email-masked]>
Date: Sat, 06 Dec 2025 13:27:58 -0500

> of Chapter 8 ("Data Types") of the PostgreSQL documentation?

Yeah, that seems like an oversight.  Will fix, thanks for noticing it.

			regards, tom lane

---

From: Erik Wienhold <[email-masked]>
Date: Mon, 8 Dec 2025 19:33:42 +0100

> Yeah, that seems like an oversight.  Will fix, thanks for noticing it.

But does Postgres' json type really map to the JSON type defined by
SQL:2023?  jsonb appears to be closer to that, although I don't have
access to that particular version of the standard.  Peter wrote [1]
about the compatibility with SQL:2023 and noted that the standard maps
more readily to jsonb (see 3rd bullet point in the notes section) and
features T879–T882 still only apply to jsonb.

I don't think we should list json in that compatibility box unless it's
an alias for jsonb (maybe in some future version).  Or at least note
that jsonb is the better choice for people looking for standard
compatibility.  To me, "compatibility" implies that Postgres also
implements certain features of those standard types rather than just
providing some type that happens to match the name of a standard type
for historical reasons.

[1] https://peter.eisentraut.org/blog/2023/04/18/postgresql-and-sql-2023

-- 
Erik Wienhold

---

From: Tom Lane <[email-masked]>
Date: Mon, 08 Dec 2025 14:36:43 -0500

> features T879–T882 still only apply to jsonb.

Well, there is the weasel wording right at the start of that <note>:

    The following types (or spellings thereof) are specified by SQL:

This note also doesn't get into the rather large semantic gap between
what SQL says TIMESTAMP WITH TIME ZONE is and what timestamptz
actually does.  I think the point of the note is mostly to say that
"you have some hope of interoperability with other DBMSes if you
use these types".

			regards, tom lane