Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 8a17f44

Browse files
committed
doc: Remove more notes about compatibilities with past versions
This is a follow-up of the work done in fa42c2e, that did not include all the fixes previously agreed on. The contents removed here can be confusing to the reader as they refer to rather old server versions. Author: Stephen Frost, Tom Lane, Heikki Linnakangas, Yaroslav Schekin Discussion: https://postgr.es/m/CAB8KJ=jYHgnxLLZSNJz7gBTck4TxomngCmGkw3nEMSNF0yL6wA@mail.gmail.com Discussion: https://postgr.es/m/1599765595731-0.post@n3.nabble.com
1 parent 57faaf3 commit 8a17f44

File tree

3 files changed

+11
-30
lines changed

3 files changed

+11
-30
lines changed

doc/src/sgml/func.sgml

+6-13
Original file line numberDiff line numberDiff line change
@@ -2309,15 +2309,11 @@ repeat('Pg', 4) <returnvalue>PgPgPgPg</returnvalue>
23092309

23102310
<note>
23112311
<para>
2312-
Before <productname>PostgreSQL</productname> 8.3, these functions would
2313-
silently accept values of several non-string data types as well, due to
2314-
the presence of implicit coercions from those data types to
2315-
<type>text</type>. Those coercions have been removed because they frequently
2316-
caused surprising behaviors. However, the string concatenation operator
2317-
(<literal>||</literal>) still accepts non-string input, so long as at least one
2318-
input is of a string type, as shown in <xref
2319-
linkend="functions-string-sql"/>. For other cases, insert an explicit
2320-
coercion to <type>text</type> if you need to duplicate the previous behavior.
2312+
The string concatenation operator (<literal>||</literal>) will accept
2313+
non-string input, so long as at least one input is of string type, as shown
2314+
in <xref linkend="functions-string-sql"/>. For other cases, inserting an
2315+
explicit coercion to <type>text</type> can be used to have non-string input
2316+
accepted.
23212317
</para>
23222318
</note>
23232319

@@ -17368,10 +17364,7 @@ SELECT NULLIF(value, '(none)') ...
1736817364
(last subscript varies most rapidly).
1736917365
If the contents of two arrays are equal but the dimensionality is
1737017366
different, the first difference in the dimensionality information
17371-
determines the sort order. (This is a change from versions of
17372-
<productname>PostgreSQL</productname> prior to 8.2: older versions would claim
17373-
that two arrays with the same contents were equal, even if the
17374-
number of dimensions or subscript ranges were different.)
17367+
determines the sort order.
1737517368
</para>
1737617369

1737717370
<table id="array-operators-table">

doc/src/sgml/gin.sgml

+5-5
Original file line numberDiff line numberDiff line change
@@ -507,7 +507,7 @@
507507
Updating a <acronym>GIN</acronym> index tends to be slow because of the
508508
intrinsic nature of inverted indexes: inserting or updating one heap row
509509
can cause many inserts into the index (one for each key extracted
510-
from the indexed item). As of <productname>PostgreSQL</productname> 8.4,
510+
from the indexed item).
511511
<acronym>GIN</acronym> is capable of postponing much of this work by inserting
512512
new tuples into a temporary, unsorted list of pending entries.
513513
When the table is vacuumed or autoanalyzed, or when
@@ -576,10 +576,10 @@
576576
</para>
577577

578578
<para>
579-
As of <productname>PostgreSQL</productname> 8.4, this advice is less
580-
necessary since delayed indexing is used (see <xref
581-
linkend="gin-fast-update"/> for details). But for very large updates
582-
it may still be best to drop and recreate the index.
579+
When <literal>fastupdate</literal> is enabled for <acronym>GIN</acronym>
580+
(see <xref linkend="gin-fast-update"/> for details), the penalty is
581+
less than when it is not. But for very large updates it may still be
582+
best to drop and recreate the index.
583583
</para>
584584
</listitem>
585585
</varlistentry>

doc/src/sgml/ref/select.sgml

-12
Original file line numberDiff line numberDiff line change
@@ -1934,18 +1934,6 @@ SELECT 2+2;
19341934
by introducing a dummy one-row table from which to do the
19351935
<command>SELECT</command>.
19361936
</para>
1937-
1938-
<para>
1939-
Note that if a <literal>FROM</literal> clause is not specified,
1940-
the query cannot reference any database tables. For example, the
1941-
following query is invalid:
1942-
<programlisting>
1943-
SELECT distributors.* WHERE distributors.name = 'Westward';
1944-
</programlisting><productname>PostgreSQL</productname> releases prior to
1945-
8.1 would accept queries of this form, and add an implicit entry
1946-
to the query's <literal>FROM</literal> clause for each table
1947-
referenced by the query. This is no longer allowed.
1948-
</para>
19491937
</refsect2>
19501938

19511939
<refsect2>

0 commit comments

Comments
 (0)