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>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
Before <productname>PostgreSQL</productname> 8.3, these functions would
|
The string concatenation operator (<literal>||</literal>) will accept
|
||||||
silently accept values of several non-string data types as well, due to
|
non-string input, so long as at least one input is of string type, as shown
|
||||||
the presence of implicit coercions from those data types to
|
in <xref linkend="functions-string-sql"/>. For other cases, inserting an
|
||||||
<type>text</type>. Those coercions have been removed because they frequently
|
explicit coercion to <type>text</type> can be used to have non-string input
|
||||||
caused surprising behaviors. However, the string concatenation operator
|
accepted.
|
||||||
(<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.
|
|
||||||
</para>
|
</para>
|
||||||
</note>
|
</note>
|
||||||
|
|
||||||
@ -17368,10 +17364,7 @@ SELECT NULLIF(value, '(none)') ...
|
|||||||
(last subscript varies most rapidly).
|
(last subscript varies most rapidly).
|
||||||
If the contents of two arrays are equal but the dimensionality is
|
If the contents of two arrays are equal but the dimensionality is
|
||||||
different, the first difference in the dimensionality information
|
different, the first difference in the dimensionality information
|
||||||
determines the sort order. (This is a change from versions of
|
determines the sort order.
|
||||||
<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.)
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<table id="array-operators-table">
|
<table id="array-operators-table">
|
||||||
|
@ -507,7 +507,7 @@
|
|||||||
Updating a <acronym>GIN</acronym> index tends to be slow because of the
|
Updating a <acronym>GIN</acronym> index tends to be slow because of the
|
||||||
intrinsic nature of inverted indexes: inserting or updating one heap row
|
intrinsic nature of inverted indexes: inserting or updating one heap row
|
||||||
can cause many inserts into the index (one for each key extracted
|
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
|
<acronym>GIN</acronym> is capable of postponing much of this work by inserting
|
||||||
new tuples into a temporary, unsorted list of pending entries.
|
new tuples into a temporary, unsorted list of pending entries.
|
||||||
When the table is vacuumed or autoanalyzed, or when
|
When the table is vacuumed or autoanalyzed, or when
|
||||||
@ -576,10 +576,10 @@
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
As of <productname>PostgreSQL</productname> 8.4, this advice is less
|
When <literal>fastupdate</literal> is enabled for <acronym>GIN</acronym>
|
||||||
necessary since delayed indexing is used (see <xref
|
(see <xref linkend="gin-fast-update"/> for details), the penalty is
|
||||||
linkend="gin-fast-update"/> for details). But for very large updates
|
less than when it is not. But for very large updates it may still be
|
||||||
it may still be best to drop and recreate the index.
|
best to drop and recreate the index.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
@ -1934,18 +1934,6 @@ SELECT 2+2;
|
|||||||
by introducing a dummy one-row table from which to do the
|
by introducing a dummy one-row table from which to do the
|
||||||
<command>SELECT</command>.
|
<command>SELECT</command>.
|
||||||
</para>
|
</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>
|
||||||
|
|
||||||
<refsect2>
|
<refsect2>
|
||||||
|
Reference in New Issue
Block a user