mirror of
https://github.com/postgres/postgres.git
synced 2025-05-02 11:44:50 +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:
parent
57faaf376e
commit
8a17f44c1e
@ -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>
|
||||||
|
Loading…
x
Reference in New Issue
Block a user