[doc][pg15 Update PG doc references from 11 to 15 (yugabyte#25695)

* Update PG doc references from 11 to 15

* tweaks

* fix links

* typo

* fixes

Author: ddhodge

docs/content/preview/api/ycql/type_jsonb.md

@@ -16,7 +16,7 @@ type: docs
 
 Use the `JSONB` data type to efficiently model JSON data. This data type makes it easy to model
 JSON data which does not have a set schema and might change often. This data type is similar to
-the [JSONB data type in PostgreSQL](https://www.postgresql.org/docs/9.4/static/datatype-json.html).
+the [JSONB data type in PostgreSQL](https://www.postgresql.org/docs/15/static/datatype-json.html).
 The JSON document is serialized into a format which is easy for search and retrieval.
 This is achieved by storing all the JSON keys in sorted order, which allows for efficient binary
 search of keys. Similarly, arrays are stored such that random access for a particular array index

docs/content/preview/api/ysql/_index.md

@@ -16,11 +16,11 @@ type: indexpage
 -->
 ## Introduction
 
-Yugabyte Structured Query Language (YSQL) is an ANSI SQL, fully-relational API that is best fit for scale-out RDBMS applications that need ultra resilience, massive write scalability, and geographic data distribution. The YugabyteDB SQL processing layer is built by using the [PostgreSQL](https://www.yugabyte.com/postgresql/) code (starting with version 11.2) directly. The result of this approach is that [YSQL is fully compatible with PostgreSQL _by construction_](https://www.yugabyte.com/postgresql/postgresql-compatibility/).
+Yugabyte Structured Query Language (YSQL) is an ANSI SQL, fully-relational API that is best fit for scale-out RDBMS applications that need ultra resilience, massive write scalability, and geographic data distribution. The YugabyteDB SQL processing layer is built by using the [PostgreSQL](https://www.yugabyte.com/postgresql/) code (version 15) directly. The result of this approach is that [YSQL is fully compatible with PostgreSQL _by construction_](https://www.yugabyte.com/postgresql/postgresql-compatibility/).
 
 YSQL therefore supports all of the traditional relational modeling features, such as referential integrity (implemented using a foreign key constraint from a child table to a primary key to its parent table), joins, partial indexes, triggers, and stored procedures. It extends the familiar transactional notions into the YugabyteDB Distributed SQL Database architecture.
 
-If you don't find what you're looking for in the YSQL documentation, you might find answers in the relevant [PostgreSQL documentation](https://www.postgresql.org/docs/11/index.html). Successive YugabyteDB releases honor PostgreSQL syntax and semantics, although some features (for example those that are specific to the PostgreSQL monolithic SQL database architecture) might not be supported for distributed SQL. The YSQL documentation specifies the supported syntax and extensions.
+If you don't find what you're looking for in the YSQL documentation, you might find answers in the relevant [PostgreSQL documentation](https://www.postgresql.org/docs/15/index.html). Successive YugabyteDB releases honor PostgreSQL syntax and semantics, although some features (for example those that are specific to the PostgreSQL monolithic SQL database architecture) might not be supported for distributed SQL. The YSQL documentation specifies the supported syntax and extensions.
 
 To find the version of the PostgreSQL processing layer used in YugabyteDB, you can use the `version()` function. The following YSQL query displays only the first part of the returned value:
 
@@ -31,7 +31,7 @@ select rpad(version(), 18)||'...' as v;
 ```output
            v
 -----------------------
- PostgreSQL 11.2-YB...
+ PostgreSQL 15.2-YB...
 ```
 
 ## YSQL components

docs/content/preview/api/ysql/cursors.md

@@ -28,7 +28,7 @@ The section **[Cursor manipulation in PL/pgSQL—the "open", "fetch", and "close
 
 ## What is a cursor?
 
-A _cursor_ is an artifact that you create with the _[declare](../the-sql-language/statements/dml_declare/)_ SQL statement—or with the equivalent PL/pgSQL _open_ statement. A _cursor's_ duration is limited to the lifetime of the session that creates it, it is private to that session, and it is identified by a bare name that must conform to the usual rules for SQL names like those of tables, schemas, and so on. In the sense that it's session-private, that its name isn't schema-qualified, that it has at most session duration, and that it has no explicit owner, it resembles a prepared statement. A session's currently extant _cursors_ are listed in the _[pg_cursors](https://www.postgresql.org/docs/11/view-pg-cursors.html)_ catalog view.
+A _cursor_ is an artifact that you create with the _[declare](../the-sql-language/statements/dml_declare/)_ SQL statement—or with the equivalent PL/pgSQL _open_ statement. A _cursor's_ duration is limited to the lifetime of the session that creates it, it is private to that session, and it is identified by a bare name that must conform to the usual rules for SQL names like those of tables, schemas, and so on. In the sense that it's session-private, that its name isn't schema-qualified, that it has at most session duration, and that it has no explicit owner, it resembles a prepared statement. A session's currently extant _cursors_ are listed in the _[pg_cursors](https://www.postgresql.org/docs/15/view-pg-cursors.html)_ catalog view.
 
 A _cursor_ is defined by a _subquery_ (typically a _select_ statement, but you can use a _values_ statement) and it lets you fetch the rows from the result set that the _subquery_ defines one-at-a-time without (in favorable cases) needing ever to materialize the entire result set in your application's client backend server process—i.e. the process that this query lists:
 
@@ -43,7 +43,7 @@ where pid = pg_backend_pid();
 
 You don't need to understand this. But it might help you to see how _cursors_ fit into the bigger picture of how  the processing of SQL statements like _select_, _values_, _insert_, _update_, and _delete_ is implemented. (These statements can all be used as the argument of the _prepare_ statement—and for this reason, they will be referred to here as _preparable_ statements.)
 
-At the lowest level, the implementation of all of SQL processing is implemented in PostgreSQL using C. And YSQL uses the same C code. The execution of a preparable statement uses C structure(s) that hold information, in the backend server process, like the SQL statement text, its parsed representation, its execution plan, and so on. Further, when the statement is currently being executed, other information is held, like the values of actual arguments that have been bound to placeholders in the SQL text and the position of the current row in the result set (when the statement produces one). You can manipulate these internal structures, from client side code, using the _[libpq - C Library](https://www.postgresql.org/docs/11/libpq.html)_ API or, at a level of abstraction above that, the _[Embedded SQL in C](https://www.postgresql.org/docs/11/ecpg.html)_ API (a.k.a. the _ECPG_). Moreover, engineers who implement PostgreSQL itself can use the [Server Programming Interface](https://www.postgresql.org/docs/current/spi.html). These APIs have schemes that let the programmer ask for the entire result set from a _subquery_ in a single round trip. And they also have schemes that let you ask for the result set row-by-row, or in batches of a specified size. See, for example, the _libpq_ subsection [Retrieving Query Results Row-By-Row](https://www.postgresql.org/docs/11/libpq-single-row-mode.html).
+At the lowest level, the implementation of all of SQL processing is implemented in PostgreSQL using C. And YSQL uses the same C code. The execution of a preparable statement uses C structure(s) that hold information, in the backend server process, like the SQL statement text, its parsed representation, its execution plan, and so on. Further, when the statement is currently being executed, other information is held, like the values of actual arguments that have been bound to placeholders in the SQL text and the position of the current row in the result set (when the statement produces one). You can manipulate these internal structures, from client side code, using the _[libpq - C Library](https://www.postgresql.org/docs/15/libpq.html)_ API or, at a level of abstraction above that, the _[Embedded SQL in C](https://www.postgresql.org/docs/15/ecpg.html)_ API (a.k.a. the _ECPG_). Moreover, engineers who implement PostgreSQL itself can use the [Server Programming Interface](https://www.postgresql.org/docs/current/spi.html). These APIs have schemes that let the programmer ask for the entire result set from a _subquery_ in a single round trip. And they also have schemes that let you ask for the result set row-by-row, or in batches of a specified size. See, for example, the _libpq_ subsection [Retrieving Query Results Row-By-Row](https://www.postgresql.org/docs/15/libpq-single-row-mode.html).
 
 In a more abstract, RDBMS-independent, discussion of the SQL processing of the statements that correspond to PostgreSQL's preparable statements, the term "cursor" is used to denote these internal structures. (You'll notice this, for example, with Oracle Database.)
 

docs/content/preview/api/ysql/datatypes/type_array/literals/_index.md

@@ -19,21 +19,26 @@ An array literal starts with a left curly brace. This is followed by some number
 To use such a literal in SQL or in PL/pgSQL it must be enquoted in the same way as is an ordinary `text` literal. You can enquote an array literal using dollar quotes, if this suits your purpose, just as you can for a `text` literal. You sometimes need to follow the closing quote with a suitable typecast operator for the array data type that you intend. And sometimes the context of use uniquely determines the literal's data type. It's never wrong to write the typecast explicitly—and it's a good practice always to do this.
 
 Here, in use in a SQL `SELECT` statement, is the literal for a one-dimensional array of primitive `int` values:
+
 ```plpgsql
 \t on
 select '{1, 2, 3}'::int[];
 ```
+
 The `\t on` meta-command suppresses column headers and the rule-off under these. Unless the headers are important for understanding, query output from `ysqlsh` will be shown, throughout the present "arrays" major section, without these.
 
 This is the output that the first example produces:
 
-```
+```output
  {1,2,3}
 ```
+
 The second example surrounds the values that the array literal defines with double quotes:
+
 ```plpgsql
 select '{"1", "2", "3"}'::int[];
 ```
+
 It produces the identical output to the first example, where no double quotes were used.
 
 The third example defines a two-dimensional array of `int` values:
@@ -49,7 +54,7 @@ select '
 
 It produces this result:
 
-```
+```output
  {{11,12,13},{21,22,23}}
 ```
 
@@ -66,10 +71,13 @@ select '
   }
 '::rt[];
 ```
+
 It produces this output:
-```
+
+```output
  {"(1,\"a1 a2\")","(2,\"b1 b2\")","(3,\"c1 v2\")"}
 ```
+
 All whitespace (except, of course, within the text values) has been removed. The double quotes around the representation of each _"row"_ type value are retained. This suggests that they are significant. (Test this by removing them. It causes the _"22P02: malformed row literal"_ error.) Most noticeably, there are clearly rules at work in connection with the representation of each `text` value within the representation of each _"row"_ type value.
 
 The following sections present the rules carefully and, when the rules allow some freedom, give recommendations.
@@ -84,6 +92,6 @@ The following sections present the rules carefully and, when the rules allow som
 
 These rules are covered in the following sections of the PostgreSQL documentation:
 
-- [8.15. Arrays](https://www.postgresql.org/docs/11/arrays.html)
+- [8.15. Arrays](https://www.postgresql.org/docs/15/arrays.html)
 
-- [8.16. Composite Types](https://www.postgresql.org/docs/11/rowtypes.html)
+- [8.16. Composite Types](https://www.postgresql.org/docs/15/rowtypes.html)