mirror of
https://git.postgresql.org/git/postgresql.git
synced 2025-01-06 15:24:56 +08:00
Update release notes in "major" and "migration" sections. Still have
remainder of release notes to review.
This commit is contained in:
Bruce Momjian
parent
56b7695cf5
commit
1246fcd02a
@ -1,4 +1,4 @@
|
|||||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.517 2007/10/10 14:09:49 momjian Exp $ -->
|
<!-- $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.518 2007/10/11 19:46:21 momjian Exp $ -->
|
||||||
<!--
|
<!--
|
||||||
|
|
||||||
Typical markup:
|
Typical markup:
|
||||||
@ -40,7 +40,7 @@ do it for earlier branch release files.
|
|||||||
|
|
||||||
<note>
|
<note>
|
||||||
<title>Release date</title>
|
<title>Release date</title>
|
||||||
<simpara>2007-??-??</simpara>
|
<simpara>2007-12-??</simpara>
|
||||||
<para>CURRENT AS OF 2007-10-03</>
|
<para>CURRENT AS OF 2007-10-03</>
|
||||||
</note>
|
</note>
|
||||||
|
|
||||||
@ -48,33 +48,48 @@ do it for earlier branch release files.
|
|||||||
<title>Overview</title>
|
<title>Overview</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This release adds many improvements that were requested by users,
|
This release represents a major leap forward by adding significant
|
||||||
including:
|
new functionality and performance enhancements to
|
||||||
|
<productname>PostgreSQL</>. Many complex ideas that normally take
|
||||||
|
years to implement were added rapidly to this release by our
|
||||||
|
development team. This release starts <productname>PostgreSQL</> on
|
||||||
|
a trajectory moving beyond feature-parity with other database
|
||||||
|
systems to a time when <productname>PostgreSQL</> will be a
|
||||||
|
technology leader in the database field. Major new capabilities
|
||||||
|
this release include:
|
||||||
|
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Full text search is now a built-in feature
|
Full text search now fully integrated into the core database
|
||||||
|
system
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Support for the SQL/XML standard, including a new <type>xml</type> builtin
|
Support for the SQL/XML standard, including a new <type>XML</type> builtin
|
||||||
data type
|
data type
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
enum data types
|
Enumerated (<type>ENUM</>) data type support
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
This is accomplished by creating a new data type with an
|
||||||
|
<literal>ENUM</> clause, e.g.
|
||||||
|
<literal>CREATE TYPE mood AS ENUM ('sad', 'ok', 'happy')</>.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
UUID data type, similar to that defined by RFC 4122
|
Universally Unique Identifier (UUID) data type, similar to that
|
||||||
|
defined by RFC 4122
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
@ -86,52 +101,68 @@ do it for earlier branch release files.
|
|||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
|
Control of whether <literal>NULL</>s sort first or last, using
|
||||||
<literal>ORDER BY ... NULLS FIRST/LAST</>
|
<literal>ORDER BY ... NULLS FIRST/LAST</>
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Updatable cursors
|
Updatable cursors using <literal>UPDATE/DELETE WHERE CURRENT OF</>
|
||||||
(<literal>UPDATE/DELETE WHERE CURRENT OF</>
|
</para>
|
||||||
<replaceable>cursor_name</>)
|
|
||||||
|
<para>
|
||||||
|
This eliminates the need to reference a primary key to update or
|
||||||
|
delete rows returned by a cursor.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Per-function parameter settings
|
Server configuration parameters can now be set on a per-function
|
||||||
|
basis
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
For example, functions can now set their own
|
||||||
|
<varname>search_path</> to prevent unexpected behavior if a
|
||||||
|
different <varname>search_path</> exists at run-time.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
User-defined types can now have type modifiers (parameters)
|
User-defined types can now have type modifiers
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Declarations such as <type>varchar(42)</type> are no longer
|
This allows a user type to take a modifier when
|
||||||
restricted to use by built-in data types.
|
being referenced, e.g. <type>SSNUM(7)</>. Previously only
|
||||||
|
predefined system data types would allow this, e.g.
|
||||||
|
<type>CHAR(4)</>.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Automatic plan invalidation when table definitions change
|
Automatically invalidate cached function code when table
|
||||||
|
definitions change
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This will particularly ease usage of temporary tables in
|
Previously PL/pgSQL functions that referenced temporary tables
|
||||||
PL/PgSQL functions.
|
would fail if the temporary table was dropped and recreated
|
||||||
|
between function invocations, unless <literal>EXECUTE</> was
|
||||||
|
used.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Numerous improvements in logging and statistics collection
|
Numerous improvements in logging and statistics collection,
|
||||||
capabilities, including the ability to emit postmaster log messages
|
including the ability to emit postmaster log messages in
|
||||||
in CSV format that can be directly loaded into a database table
|
<acronym>CSV</> format, which can be loaded into a database
|
||||||
for analysis
|
table for analysis
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
@ -139,6 +170,11 @@ do it for earlier branch release files.
|
|||||||
<para>
|
<para>
|
||||||
SSPI/GSSAPI authentication support
|
SSPI/GSSAPI authentication support
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
This adds native Security Service Provider Interface (SSPI) for
|
||||||
|
Windows.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
@ -147,58 +183,81 @@ do it for earlier branch release files.
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Autovacuum is now considered mature enough to be enabled by default.
|
This allows multiple vacuums to run concurrently, meaning
|
||||||
|
vacuuming of a large table will not prevent smaller tables from
|
||||||
|
being vacuumed at the same time. Autovacuum is now considered
|
||||||
|
mature and thus enabled by default.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The entire <productname>PostgreSQL</productname> system can
|
The backend database server can now be compiled with
|
||||||
now be compiled with Microsoft Visual C++
|
<productname>Microsoft Visual C++</>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This will improve the ability of Windows-based developers to
|
Windows executables made with Visual C++ might have better
|
||||||
contribute to the project. Windows executables made with Visual C++
|
stability and performance than those made with other tool sets.
|
||||||
may also have better stability and performance than those made with
|
Development and debugging tools familiar to Windows developers
|
||||||
other tool sets.
|
will also work.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
|
||||||
Major performance improvements in this release include:
|
Major performance improvements are listed below. Fortunately, most
|
||||||
|
of these enhancements are automatic and require user changes or
|
||||||
|
tuning:
|
||||||
|
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Asynchronous commit option to allow transactions to be reported
|
Asynchronous commit option allows transactions to be committed
|
||||||
committed before they have actually been flushed to disk
|
but on-disk changes to be delayed
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This would not, of course, be acceptable if the client takes some
|
This feature dramatically increases performance for data
|
||||||
critical external action on the assumption that the transaction
|
modification queries. The disadvantage is that because on-disk
|
||||||
will be remembered; but for certain applications, it is an acceptable
|
changes are delayed, if the operating system crashes before data
|
||||||
risk for some or all transactions to use this mode. Unlike existing
|
is written to the disk, committed data will be lost. This is
|
||||||
options such as <varname>fsync</varname>, asynchronous commit does
|
useful only for applications that can accept some data loss.
|
||||||
not risk database corruption; the worst case is that after a crash,
|
Unlike <varname>fsync</varname>, asynchronous commit does not
|
||||||
the last few reportedly-committed transactions will not have
|
risk database corruption; the worst case is that after an
|
||||||
taken effect.
|
operating system crash the last few reportedly-committed
|
||||||
|
transactions will be missing.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<quote>Distributed</> checkpoints to spread out the I/O load of a
|
<quote>Distributed</> checkpoints prevent I/O spikes during
|
||||||
checkpoint
|
checkpoints
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Previously all modified buffers were forced to disk at
|
||||||
|
checkpoint time, causing an I/O spike and decreasing server
|
||||||
|
performance. This new capability spreads checkpoint activity out
|
||||||
|
between checkpoints, reducing peak I/O usage.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Heap-Only Tuples (HOT) to reduce overhead of updates
|
Heap-Only Tuples (<acronym>HOT</>) improves <command>UPDATE</>
|
||||||
|
space usage
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
To allow high concurrency <productname>PostgreSQL</> retains old
|
||||||
|
versions of updated rows. Previously only <command>VACUUM</>
|
||||||
|
could reuse space taken by dead rows. With <acronym>HOT</> dead
|
||||||
|
row space can be reused at the time of <command>UPDATE</> or
|
||||||
|
<command>INSERT</>. This allows for more consistent performance.
|
||||||
|
<acronym>HOT</> also improved deleted row space reuse.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
@ -207,41 +266,66 @@ do it for earlier branch release files.
|
|||||||
Just-in-time background writer strategy to improve disk write
|
Just-in-time background writer strategy to improve disk write
|
||||||
efficiency
|
efficiency
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
This basically makes the background writer self-tuning.
|
||||||
|
</para>
|
||||||
|
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Reduction of on-disk data size through reducing both per-tuple
|
Reduction of both per-field and per-row storage requirements
|
||||||
and per-field overheads
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Variable-length data types with data values less then 128 bytes
|
||||||
|
will see a decrease of 3-6 bytes. For example, two
|
||||||
|
<type>CHAR(1)</type> fields now take 4 bytes instead of 16. Rows
|
||||||
|
are also 4 bytes shorter.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Efficiency improvements for large sequential scans, including
|
Prevent large sequential scans from forcing out more frequently
|
||||||
prevention of cache flushing and <quote>piggybacking</quote> to let
|
used cached pages
|
||||||
concurrent scans read the table only once
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Top-N sorting
|
Allow large sequential scans to use cached pages from other
|
||||||
|
concurrent sequential scans
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
This is accomplished by starting the new sequential scan in the
|
||||||
|
middle of the table (where the other sequential scan is already
|
||||||
|
in-progress) and wrapping around to the beginning to finish.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Lazy XID assignment to reduce the cost of read-only transactions
|
Allow <literal>ORDER BY ... LIMIT</> to be done without sorting
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
For applications in which there are a large number of read-only
|
This is done by scanning the table and using a filter to find
|
||||||
transactions, this helps not only by reducing overhead for the
|
the few requested rows, rather than sorting the entire table.
|
||||||
transactions themselves, but by reducing overhead that's driven
|
</para>
|
||||||
by the rate of XID consumption; notably, reducing contention for
|
</listitem>
|
||||||
transaction log buffers and reducing the frequency of
|
|
||||||
anti-wraparound vacuuming.
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Use pseudo-transaction ids in read-only transactions
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
This reduces transaction overhead for read-only transactions,
|
||||||
|
and reduces the need for vacuuming for transaction id
|
||||||
|
wrap-around.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
@ -268,8 +352,8 @@ do it for earlier branch release files.
|
|||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<filename>contrib/tsearch2</> features have been absorbed into
|
<filename>contrib/tsearch2</> features have been moved into
|
||||||
the core, with some syntax changes
|
the core server, with some minor syntax changes
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -279,23 +363,23 @@ do it for earlier branch release files.
|
|||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Casts to <type>text</type> that formerly occurred implicitly may now
|
Queries that previously automatically cast values to
|
||||||
need to be written explicitly
|
<type>TEXT</type> might now need explicit casts
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Data types other than <type>char</> and <type>varchar</> are no
|
Data types other than <type>CHAR</> and <type>VARCHAR</> no
|
||||||
longer implicitly castable to <type>text</>, except in the limited
|
longer automatically cast to <type>TEXT</>, except in the
|
||||||
case of a <literal>||</> (concatenation) operator whose other
|
limited case of concatenation (<literal>||</>) where the other
|
||||||
input is textual. While this will require explicit casts in a
|
input is textual. While this change will require additional
|
||||||
few queries that didn't need them before, the elimination of
|
casts for some queries it also eliminates some unusual
|
||||||
surprising interpretations justifies it.
|
behavior.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Numerous changes in administrator-only configuration parameters
|
Numerous changes in administrative server parameters
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -310,9 +394,10 @@ do it for earlier branch release files.
|
|||||||
<varname>track_activities</>.
|
<varname>track_activities</>.
|
||||||
<varname>stats_block_level</> and <varname>stats_row_level</>
|
<varname>stats_block_level</> and <varname>stats_row_level</>
|
||||||
are merged into <varname>track_counts</>.
|
are merged into <varname>track_counts</>.
|
||||||
<varname>archive_command</> changed meaning slightly: you must now set
|
Previously <varname>archive_command</> controlled whether
|
||||||
<varname>archive_mode</> to <literal>on</> as well to enable archiving.
|
archiving was performed. Now a new boolean configuration
|
||||||
The default autovacuum-related settings changed.
|
parameter, <varname>archive_mode</>, controls this. Autovacuum's
|
||||||
|
default settings have changed.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
@ -321,121 +406,126 @@ do it for earlier branch release files.
|
|||||||
Commenting out a parameter in <filename>postgresql.conf</> now
|
Commenting out a parameter in <filename>postgresql.conf</> now
|
||||||
causes it to revert to its default value
|
causes it to revert to its default value
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
|
||||||
|
|
||||||
<listitem>
|
|
||||||
<para>
|
<para>
|
||||||
<literal>ARRAY(SELECT ...)</literal> now returns an empty array,
|
Previously commenting out a value kept the value unchanged until
|
||||||
rather than a NULL, when the sub-select returns zero rows
|
the next server restart.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<literal>ORDER BY ... USING</> <replaceable>operator</>
|
<literal>ARRAY(SELECT ...)</literal>, where <command>SELECT</>
|
||||||
will now be rejected if the <replaceable>operator</> is not a
|
returns no rows, now returns an empty array, rather than NULL
|
||||||
less-than or greater-than member of some btree operator class
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
This prevents less-than-sane behavior that formerly ensued if an
|
|
||||||
operator that doesn't actually define a proper sort ordering was
|
|
||||||
specified.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The array type associated with a type named <quote>foo</quote>
|
<literal>ORDER BY ... USING</> <replaceable>operator</> now must
|
||||||
is not necessarily named <quote>_foo</quote> anymore
|
use a less-than or greater-than <replaceable>operator</> that is
|
||||||
|
defined in a btree operator class
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
This restriction was added to prevent unexpected results.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
The array name for a base data type is no longer required to
|
||||||
|
be the data type name with an underscore prefix
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The old naming convention is still honored when possible, but
|
The old naming convention is still honored when possible, but
|
||||||
client code should migrate away from depending on it.
|
client code should no longer depending on it.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
By default, non-superuser database owners can now instantiate trusted
|
Non-superuser database owners now have privileges to add trusted
|
||||||
procedural languages in their databases
|
procedural languages in their databases by default
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
While this is reasonably safe, some administrators may wish to
|
While this is reasonably safe, some administrators may wish to
|
||||||
revoke the privilege.
|
revoke the privilege. It is controlled by
|
||||||
|
<structname>pg_pltemplate</>.<structfield>tmpldbacreate</>.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The effects of <command>SET LOCAL</command> now persist until
|
<command>SET LOCAL</command> changes now persist until
|
||||||
the end of the current top transaction, unless rolled back
|
the end of the top-most transaction, unless rolled back
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
In 8.0 through 8.2, <command>SET LOCAL</command>'s
|
Previously <command>SET LOCAL</command>'s effects reverted
|
||||||
effects disappeared at subtransaction commit, leading to behavior
|
during subtransaction commit and <command>RELEASE</>.
|
||||||
that made little sense at the SQL level (one would not normally
|
|
||||||
expect <command>RELEASE</> to do such a thing).
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Commands that are disallowed in transaction blocks are now disallowed
|
Commands that are disallowed in transaction blocks are now also
|
||||||
in multiple-statement query strings, too
|
disallowed in multiple-statement query strings
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
For example, <literal>BEGIN; DROP DATABASE; COMMIT</> will now be
|
For example, <literal>BEGIN; DROP DATABASE; COMMIT</> will now be
|
||||||
rejected even if submitted as a single Query message. This was always
|
rejected even if submitted as a single query message.
|
||||||
quite unsafe, but the <function>PreventTransactionChain</function>
|
|
||||||
test failed to detect it.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Additional checks for invalidly-encoded multibyte strings
|
Add additional checks for invalidly-encoded multibyte strings
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Some cases that might formerly have allowed invalid data to
|
For example, <function>chr()</function> has additional checks.
|
||||||
enter the database will now be rejected. In particular, the
|
|
||||||
<function>chr()</function> function changed behavior.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<function>convert()</function> family of functions changed behavior
|
<function>convert()</function> encoding has changed behavior
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Strings that are not in the database's native encoding are now
|
<type>bytea</> is now used for strings that do not match the
|
||||||
represented as type <type>bytea</> rather than type <type>text</>.
|
server encoding, and <function>convert_from</> and
|
||||||
|
<function>convert_to</> have been added for consistency.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Minor security restrictions added to database-size inquiry functions
|
Restrict object size functions to users who have reasonable
|
||||||
and some contrib functions
|
permissions to view such information
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
For example, database size now requires <literal>CONNECT</>
|
||||||
|
permission, and tablespaces size requires <literal>CREATE</>
|
||||||
|
permission.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
C code that manipulates variable-length datums will need changes
|
New C macros for handling variable-length data values
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The new <function>SET_VARSIZE()</> macro <emphasis>must</> be used
|
The new <function>SET_VARSIZE()</> macro <emphasis>must</> be
|
||||||
to set the length word of a generated datum. Also, it may be
|
used to set the length of generated values. Also, it might be
|
||||||
necessary to <quote>detoast</quote> input varlena datums in cases
|
necessary to expand (<quote>de-TOAST</quote>) input values in
|
||||||
where no toasting could have happened before.
|
additional places.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user