mirror of
https://github.com/postgres/postgres.git
synced 2025-06-16 06:01:02 +03:00
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
This commit is contained in:
@ -2309,15 +2309,11 @@ repeat('Pg', 4) <returnvalue>PgPgPgPg</returnvalue>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Before <productname>PostgreSQL</productname> 8.3, these functions would
|
||||
silently accept values of several non-string data types as well, due to
|
||||
the presence of implicit coercions from those data types to
|
||||
<type>text</type>. Those coercions have been removed because they frequently
|
||||
caused surprising behaviors. However, the string concatenation operator
|
||||
(<literal>||</literal>) still accepts non-string input, so long as at least one
|
||||
input is of a string type, as shown in <xref
|
||||
linkend="functions-string-sql"/>. For other cases, insert an explicit
|
||||
coercion to <type>text</type> if you need to duplicate the previous behavior.
|
||||
The string concatenation operator (<literal>||</literal>) will accept
|
||||
non-string input, so long as at least one input is of string type, as shown
|
||||
in <xref linkend="functions-string-sql"/>. For other cases, inserting an
|
||||
explicit coercion to <type>text</type> can be used to have non-string input
|
||||
accepted.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
@ -17368,10 +17364,7 @@ SELECT NULLIF(value, '(none)') ...
|
||||
(last subscript varies most rapidly).
|
||||
If the contents of two arrays are equal but the dimensionality is
|
||||
different, the first difference in the dimensionality information
|
||||
determines the sort order. (This is a change from versions of
|
||||
<productname>PostgreSQL</productname> prior to 8.2: older versions would claim
|
||||
that two arrays with the same contents were equal, even if the
|
||||
number of dimensions or subscript ranges were different.)
|
||||
determines the sort order.
|
||||
</para>
|
||||
|
||||
<table id="array-operators-table">
|
||||
|
@ -507,7 +507,7 @@
|
||||
Updating a <acronym>GIN</acronym> index tends to be slow because of the
|
||||
intrinsic nature of inverted indexes: inserting or updating one heap row
|
||||
can cause many inserts into the index (one for each key extracted
|
||||
from the indexed item). As of <productname>PostgreSQL</productname> 8.4,
|
||||
from the indexed item).
|
||||
<acronym>GIN</acronym> is capable of postponing much of this work by inserting
|
||||
new tuples into a temporary, unsorted list of pending entries.
|
||||
When the table is vacuumed or autoanalyzed, or when
|
||||
@ -576,10 +576,10 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
As of <productname>PostgreSQL</productname> 8.4, this advice is less
|
||||
necessary since delayed indexing is used (see <xref
|
||||
linkend="gin-fast-update"/> for details). But for very large updates
|
||||
it may still be best to drop and recreate the index.
|
||||
When <literal>fastupdate</literal> is enabled for <acronym>GIN</acronym>
|
||||
(see <xref linkend="gin-fast-update"/> for details), the penalty is
|
||||
less than when it is not. But for very large updates it may still be
|
||||
best to drop and recreate the index.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -1934,18 +1934,6 @@ SELECT 2+2;
|
||||
by introducing a dummy one-row table from which to do the
|
||||
<command>SELECT</command>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Note that if a <literal>FROM</literal> clause is not specified,
|
||||
the query cannot reference any database tables. For example, the
|
||||
following query is invalid:
|
||||
<programlisting>
|
||||
SELECT distributors.* WHERE distributors.name = 'Westward';
|
||||
</programlisting><productname>PostgreSQL</productname> releases prior to
|
||||
8.1 would accept queries of this form, and add an implicit entry
|
||||
to the query's <literal>FROM</literal> clause for each table
|
||||
referenced by the query. This is no longer allowed.
|
||||
</para>
|
||||
</refsect2>
|
||||
|
||||
<refsect2>
|
||||
|
Reference in New Issue
Block a user