postgres.git / summary / log / commit / refs

commit    7bdd489d3d32d6ab5af1d2b22eaf8cc7dc148027
Author:   David Rowley <drowley@postgresql.org>
Date:     Wed Apr 20 03:17:56 2022 +0000

    Doc: use "an SQL" consistently rather than "a SQL"
    
    Similarly to what was done in 04539e73f, we standardized on SQL being
    pronounced "es-que-ell" rather than "sequel" in our documentation.
    
    Two inconsistencies have crept in during the v15 cycle.  The others
    existed before but were missed in 04539e73f due to none of the searches
    accounting for "SQL" being wrapped in tags.
    
    As with 04539e73f, we don't touch code comments here in order to not
    create unnecessary back-patching pain.
    
    Discussion: https://postgr.es/m/CAApHDvpML27UqFXnrYO1MJddsKVMQoiZisPvsAGhKE_tsKXquw%40mail.gmail.com


doc/src/sgml/func.sgml | 4 ++-- doc/src/sgml/ref/select.sgml | 2 +- doc/src/sgml/xfunc.sgml | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 489184a4f04..5804069e6a3 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -19007,7 +19007,7 @@ SELECT JSON_VALUE(jsonb '[1,2]', 'strict $[*]' DEFAULT 1 ON ERROR); <listitem> <para> Defines whether to wrap a returned sequence of <acronym>SQL/JSON</acronym> - items into a <acronym>SQL/JSON</acronym> array. + items into an <acronym>SQL/JSON</acronym> array. </para> <variablelist> <varlistentry> @@ -19819,7 +19819,7 @@ JSON_SERIALIZE ( <title>Description</title> <para> - The <function>JSON_SERIALIZE</function> function transforms a SQL/JSON value + The <function>JSON_SERIALIZE</function> function transforms an SQL/JSON value into a character or binary string. </para> </sect5> diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml index 16bbab52c3e..8e5b83dfded 100644 --- a/doc/src/sgml/ref/select.sgml +++ b/doc/src/sgml/ref/select.sgml @@ -1715,7 +1715,7 @@ SELECT * FROM (SELECT * FROM mytable FOR UPDATE) ss ORDER BY column1; <para> At the <literal>REPEATABLE READ</literal> or <literal>SERIALIZABLE</literal> transaction isolation level this would cause a serialization failure (with - a <literal>SQLSTATE</literal> of <literal>'40001'</literal>), so there is + an <literal>SQLSTATE</literal> of <literal>'40001'</literal>), so there is no possibility of receiving rows out of order under these isolation levels. </para> </caution> diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml index a34723030b0..fb8255f136e 100644 --- a/doc/src/sgml/xfunc.sgml +++ b/doc/src/sgml/xfunc.sgml @@ -445,7 +445,7 @@ $$ LANGUAGE SQL; <para> If the final <literal>SELECT</literal> or <literal>RETURNING</literal> - clause in a <acronym>SQL</acronym> function does not return exactly + clause in an <acronym>SQL</acronym> function does not return exactly the function's declared result type, <productname>PostgreSQL</productname> will automatically cast the value to the required type, if that is possible with an implicit [parent: 344a225cb9d4]