- Prior to
PostgreSQL 7.4, the precision in
- float(p) was taken to mean
- so many decimal digits. This has been corrected to match the SQL
- standard, which specifies that the precision is measured in binary
- digits. The assumption that real and
+ The assumption that real and
double precision have exactly 24 and 53 bits in the
mantissa respectively is correct for IEEE-standard floating point
implementations. On non-IEEE platforms it might be off a little, but
-
- Prior to
PostgreSQL 7.3,
serial- implied UNIQUE. This is no longer automatic. If
- you wish a serial column to have a unique constraint or be a
- primary key, it must now be specified, just like
- any other data type.
-
-
-
To insert the next value of the sequence into the serial
column, specify that the serial
The SQL standard requires that writing just timestamp
be equivalent to timestamp without time
zone, and
PostgreSQL honors that
- behavior. (Releases prior to 7.3 treated it as timestamp
- with time zone.) timestamptz is accepted as an
+ behavior. timestamptz is accepted as an
abbreviation for timestamp with time zone; this is a
within a single transaction. In practice this limit is not a
problem — note that the limit is on the number of
SQL commands, not the number of rows processed.
- Also, as of
PostgreSQL 8.3, only commands
- that actually modify the database contents will consume a command
- identifier.
+ Also, only commands that actually modify the database contents will
+ consume a command identifier.
- In
PostgreSQL versions before 7.3,
- table names beginning with pg_ were reserved. This is
- no longer true: you can create such a table name if you wish, in
- any non-system schema. However, it's best to continue to avoid
- such names, to ensure that you won't suffer a conflict if some
+ Since system table names begin with pg_, it is best to
+ avoid such names to ensure that you won't suffer a conflict if some
future version defines a system table named the same as your
table. (With the default search path, an unqualified reference to
your table name would then be resolved as the system table instead.)
or on the make command line.
-
- Changing PG_CONFIG only works when building
- against
PostgreSQL 8.3 or later.
- With older releases it does not work to set it to anything except
- pg_config; you must alter your PATH
- to select the installation to build against.
-
-
-
You can also run make in a directory outside the source
tree of your extension, if you want to keep the build directory separate.
- Prior to
PostgreSQL 8.0, casting an
- integer to bit(n) would copy the leftmost n
- bits of the integer, whereas now it copies the rightmost n
- bits. Also, casting an integer to a bit string width wider than
- the integer itself will sign-extend on the left.
+ Casting an integer to bit(n) copies the rightmost
+ n bits. Casting an integer to a bit string width wider
+ than the integer itself will sign-extend on the left.
If you disagree with this, please write your complaint to:
Pope, Cathedral Saint-Peter of Roma, Vatican.
-
-
PostgreSQL releases before 8.0 did not
- follow the conventional numbering of centuries, but just returned
- the year field divided by 100.
-
Years in the 1900s are in the second millennium.
The third millennium started January 1, 2001.
-
-
PostgreSQL releases before 8.0 did not
- follow the conventional numbering of millennia, but just returned
- the year field divided by 1000.
-
next nextval will return exactly the specified
value, and sequence advancement commences with the following
nextval. Furthermore, the value reported by
- currval is not changed in this case (this is a change
- from pre-8.3 behavior). For example,
+ currval is not changed in this case. For example,
SELECT setval('foo', 42); Next nextval will return 43
PQTRANS_ACTIVE is reported only when a query
has been sent to the server and not yet completed.
-
-
- PQtransactionStatus will give incorrect results when using
- a
PostgreSQL 7.3 server that has the parameter autocommit- set to off. The server-side autocommit feature has been
- deprecated and does not exist in later server versions.
-
-
WHERE p.locked_row = a.ctid;
- Be aware however that (as of
PostgreSQL 8.3) such a- query will be very inefficient.
+ Be aware however that such a query will be very inefficient.
END;
$$ LANGUAGE plpgsql;
- The other way, which was the only way available before
-
PostgreSQL 8.0, is to explicitly
- declare an alias, using the declaration syntax
+ The other way is to explicitly declare an alias, using the
+ declaration syntax
name ALIAS FOR $n;
- As of
PostgreSQL 7.4, PL/Python is only
- available as an untrusted language, meaning it does not
- offer any way of restricting what users can do in it. It has
- therefore been renamed to plpythonu. The trusted
- variant plpython might become available again in future,
- if a new secure execution mechanism is developed in Python. The
+ PL/Python is only available as an untrusted language, meaning
+ it does not offer any way of restricting what users can do in it and
+ is therefore named plpythonu. A trusted
+ variant plpython might become available in the future
+ if a secure execution mechanism is developed in Python. The
writer of a function in untrusted PL/Python must take care that the
function cannot be used to do anything unwanted, since it will be
able to do anything that could be done by a user logged in as the
mostly because of requirements of the SQL standard.)
- Prior to
PostgreSQL 7.3, every function that had- the same name as a data type, returned that data type, and took one
- argument of a different type was automatically a cast function.
- This convention has been abandoned in face of the introduction of
- schemas and to be able to represent binary-coercible casts in the
- system catalogs. The built-in cast functions still follow this naming
- scheme, but they have to be shown as casts in the system catalog
- pg_cast as well.
-
-
While not required, it is recommended that you continue to follow this old
convention of naming cast implementation functions after the target data
- Prior to
PostgreSQL 8.0,
CREATE- TABLE AS always included OIDs in the table it
- created. As of
PostgreSQL 8.0,
- the CREATE TABLE AS command allows the user to
+ The CREATE TABLE AS command allows the user to
explicitly specify whether OIDs should be included. If the
presence of OIDs is not explicitly specified,
the configuration variable is
- used. As of
PostgreSQL 8.1,
- this variable is false by default, so the default behavior is not
- identical to pre-8.0 releases. Applications that
- require OIDs in the table created by CREATE TABLE
- AS should explicitly specify WITH (OIDS)
- to ensure desired behavior.
+ used.
Notes
- The option was added in
-
PostgreSQL 7.2. In prior releases, the server include files were- installed in the same location as the client headers, which could
- be queried with the option . To make your
- package handle both cases, try the newer option first and test the
- exit status to see whether it succeeded.
-
-
The options , ,
, ,
The option
was added in
PostgreSQL 8.4. The option
was added in
PostgreSQL 9.0.
-
- In releases prior to
PostgreSQL 7.1, before- pg_config came to be, a method for finding the
- equivalent configuration information did not exist.
-
reindex anything.
- Prior to
PostgreSQL 8.1,
REINDEX- DATABASE processed only system indexes, not all indexes as one would
- expect from the name. This has been changed to reduce the surprise
- factor. The old behavior is available as REINDEX SYSTEM.
-
-
- Prior to
PostgreSQL 7.4,
REINDEX- TABLE did not automatically process TOAST tables, and so those had
- to be reindexed by separate commands. This is still possible, but
- redundant.
-
- Prior to
PostgreSQL 8.1, the table created by- SELECT INTO included OIDs by default. In
-
PostgreSQL 8.1, this is not the case
- — to include OIDs in the new table, the
- linkend="guc-default-with-oids"> configuration variable must be
- enabled. Alternatively, CREATE TABLE AS can be
+ To add OIDs to the table created by SELECT INTO,
+ enable the configuration
+ variable. Alternatively, CREATE TABLE AS can be
used with the WITH OIDS clause.
-
- (This system was established in
PostgreSQL 7.3.- In versions before that, the command status might show different
- results when rules exist.)
these required items, the cluster configuration files
postgresql.conf, pg_hba.conf, and
pg_ident.conf are traditionally stored in
-
PGDATA (although in PostgreSQL 8.0 and-later, it is possible to place them elsewhere).
+PGDATA, although it is possible to place them elsewhere.
- Before
PostgreSQL release 8.0, the requirement
- that STABLE and IMMUTABLE functions cannot modify
- the database was not enforced by the system. Releases 8.0 and later enforce it
- by requiring SQL functions and procedural language functions of these
- categories to contain no SQL commands other than SELECT.
+
PostgreSQL requires that
STABLE+ and IMMUTABLE functions contain no SQL commands other
+ than SELECT to prevent data modification.
(This is not a completely bulletproof test, since such functions could
still call VOLATILE functions that modify the database.
If you do that, you will find that the STABLE or
projects / postgresql.git / commitdiff