"http://gborg.postgresql.org">http://gborg.postgresql.org.
one supplied by the operating system. This will provide consistent
behavior across all platforms. In most cases, there should be
little noticeable difference in time zone behavior, except that
- the time zone names used by SET/SHOW TimeZone> may
+ the time zone names used by SET>/SHOW>
+ TimeZone> may
be different from what your platform provides.
-
- EXECUTE now returns a completion tag that
- matches the executed statement.
-
-
-
Configure>'s threading option no longer requires
-
- Syntax checking of array input values has been tightened up
- considerably. Junk that was previously allowed in odd places with
- odd results now causes an error. Empty-string element values
- must now be written as "">, rather than writing nothing.
- Also changed behavior with respect to whitespace surrounding
- array elements: trailing whitespace is now ignored, for symmetry
- with leading whitespace (which has always been ignored).
-
-
-
-
- In
- now see the results of concurrent transactions committed up to the
- beginning of each statement within the function, rather than up to the
- beginning of the interactive command that called the function.
-
-
-
-
- Functions declared
- use the snapshot of the calling query, and therefore do not see the
- effects of actions taken after the calling query starts, whether in
- their own transaction or other transactions. Such a function must be
- read-only, too, meaning that it cannot use any SQL commands other than
- SELECT>.
-
-
-
-
- Non-deferred
- after completion of the triggering query, rather than upon
- finishing the current interactive command. This makes a
- difference when the triggering query occurred within a function:
- the trigger is invoked before the function proceeds to its next
- operation.
-
-
-
-
- CIDR> values now must have their non-masked bits be zero.
- For example, we no longer allow
- 204.248.199.1/31 as a CIDR> value. Such
- values should never have been accepted by
-
PostgreSQL and will now be rejected.
-
-
-
-
The 8.1 release will remove the function
- to_char(interval)>.
+ to_char(interval, text)>.
+
+ The server now warns of empty strings passed to
+ oid/float4/float8 data
+ types, but continues to interpret them as zeroes as before.
+ In the next major release, empty strings will be considered
+ invalid input for these data types.
+
+
+
By default, tables in
PostgreSQL 8.0
this will not be the case: to create a table
that contains OID>s, the
be specified or the default_with_oids
- configuration parameter must be enabled. Users are encouraged to
+ configuration parameter must be set. Users are encouraged to
explicitly specify
require OIDs for compatibility with future releases of
In previous releases, the checkpoint process, which runs every few
minutes, would write all dirty buffers to the operating system's
buffer cache then flush all dirty operating system buffers to
- disk. This often resulted in a periodic spike in disk usage that
+ disk. This resulted in a periodic spike in disk usage that often
hurt performance. The new code uses a background writer to trickle
disk writes at a steady pace so checkpoints have far fewer dirty
pages to write to disk. Also, the new code does not issue a global
Use dynamically-generated table size estimates while planning (Tom)
- The optimizer now uses a table's current actual size on disk as its
- estimate of the number of blocks in the table, and it makes an estimate
- of the number of rows in the table based on the current size on disk.
- Formerly, the
- pg_class.relpages
- and
- pg_class.reltuples
- fields were used as-is, but these values might be quite out-of-date,
- leading to poor choices of plans. They are now treated only as an
- indication of the table's density (rows per page).
+ Formerly the planner estimated table sizes using the values seen
+ by the last VACUUM or ANALYZE,
+ both as to physical table size (number of pages) and number of rows.
+ Now, the current physical table size is obtained from the kernel,
+ and the number of rows is estimated by multiplying the table size
+ by the row density (rows per page) seen by the last
+ VACUUM or ANALYZE. This should
+ produce more reliable estimates in cases where the table size has
+ changed significantly since the last housekeeping command.
- Allow collection of ANALYZE statistics for
+ ANALYZE now collects statistics for
expression indexes (Tom)
-
- Improve optimizer rowcount estimates (Tom)
-
- Formerly the planner estimated table sizes using the values seen
- by the last VACUUM or ANALYZE,
- both as to physical table size (number of pages) and number of rows.
- Now, the physical table size is obtained directly from the kernel,
- and the number of rows is estimated by multiplying the table size
- by the row density (rows per page) seen by the last
- VACUUM or ANALYZE. This should
- produce more reliable estimates in cases where the table size has
- changed significantly since the last housekeeping command.
-
-
-
- Add new read-only server configuration parameters to query server
+ Add new read-only server configuration parameters to show server
compile-time settings: block_size>,
integer_datetimes>, max_function_args>,
max_identifier_length>, max_index_keys> (Joe)
parameters with a unified listen_addresses> parameter
(Andrew, Tom)
+ virtual_host> could only specify a single IP address to
+ listen on. listen_addresses> allows multiple addresses
+ to be specified.
+
parameters to be used in the query. In this release, planning of
unnamed prepared statements is delayed until the first execution,
and the actual parameter values of that execution are used as
- optimization hints.
+ optimization hints. This allows use of out-of-line parameter passing
+ without incurring a performance penalty.
control whether tables are created with OID>s by default (Neil)
- This allows administrators to default all CREATE
- TABLE commands to create tables without OID>
- columns.
+ This allows administrators to control whether CREATE
+ TABLE commands create tables with or without OID>
+ columns by default. (Note: the current factory default setting for
+ default_with_oids> is TRUE>, but the default
+ will become FALSE> in future releases.)
- Constraint/Index/SERIAL> names are now table_column_type
+ Constraint/Index/SERIAL> names are now
+ table_column_type>
with numbers appended to guarantee uniqueness within the schema
(Tom)
PostgreSQL uses the user name as salt
- when encrypting passwords via MD5. When a user name is changed,
- their salt no longer matches the stored MD5 password, so the
+ when encrypting passwords via MD5. When a user's name is changed,
+ the salt will no longer match the stored MD5 password, so the
stored password becomes useless. In this release a notice is
generated and the password is cleared. A new password must then
- be assigned.
+ be assigned if the user is to be able to log in with a password.
Formerly, the parser would select these operators in many situations
where an unable to select an operator> error would be more
appropriate, such as null * null>. If you actually want
- to do arithmetic on a "char"> column, you can cast it to integer.
+ to do arithmetic on a "char"> column, you can cast it to
+ integer explicitly.
- Warn of empty string being passed to
+ Warn about empty string being passed to
OID>/float4>/float8> data types (Neil)
- Allow
- int2>/int4>/int8>/float4>/float8>
- input routines to have leading or trailing whitespace
+ Allow leading or trailing whitespace in
+ int2>/int4>/int8>/float4>/float8>
+ input routines
(Neil)
effects of actions taken after the calling query starts, whether in
their own transaction or other transactions. Such a function must be
read-only, too, meaning that it cannot use any SQL commands other than
- SELECT>.
+ SELECT>. There is a considerable performance gain from
+ declaring a function STABLE> or IMMUTABLE>
+ rather than VOLATILE>.
- Make libpq thread-safe (Bruce)
+ Make libpq's thread-safe (Bruce)
- Removed contrib/pg_logger>
+ Removed contrib/pg_logger>: obsoleted by integrated logging
+ subprocess