A dump/restore is not required for those running 7.4.X. However,
if you are upgrading from a version earlier than 7.4.11, see
Section E.279.

Full security against the SQL-injection attacks described in
CVE-2006-2313 and CVE-2006-2314 might require changes in
application code. If you have applications that embed untrustworthy
strings into SQL commands, you should examine them as soon as
possible to ensure that they are using recommended escaping
techniques. In most cases, applications should be using subroutines
provided by libraries or drivers (such as libpq's PQescapeStringConn()) to perform string escaping,
rather than relying on ad hoc code to
do it.

Change the server to reject invalidly-encoded multibyte
characters in all cases (Tatsuo, Tom)

While PostgreSQL has been
moving in this direction for some time, the checks are now applied
uniformly to all encodings and all textual input, and are now
always errors not merely warnings. This change defends against
SQL-injection attacks of the type described in CVE-2006-2313.

Reject unsafe uses of \' in string
literals

As a server-side defense against SQL-injection attacks of the
type described in CVE-2006-2314, the server now only accepts
'' and not \' as
a representation of ASCII single quote in SQL string literals. By
default, \' is rejected only when
client_encoding is set to a client-only
encoding (SJIS, BIG5, GBK, GB18030, or UHC), which is the scenario
in which SQL injection is possible. A new configuration parameter
backslash_quote is available to adjust
this behavior when needed. Note that full security against
CVE-2006-2314 might require client-side changes; the purpose of
backslash_quote is in part to make it
obvious that insecure clients are insecure.

Modify libpq's string-escaping
routines to be aware of encoding considerations and standard_conforming_strings

This fixes libpq-using
applications for the security issues described in CVE-2006-2313 and
CVE-2006-2314, and also future-proofs them against the planned
changeover to SQL-standard string literal syntax. Applications that
use multiple PostgreSQL
connections concurrently should migrate to PQescapeStringConn() and PQescapeByteaConn() to ensure that escaping is
done correctly for the settings in use in each database connection.
Applications that do string escaping "by
hand" should be modified to rely on library routines
instead.

Submit correction

If you see anything in the documentation that is not correct, does not match
your experience with the particular feature or requires further clarification,
please use
this form
to report a documentation issue.