<note>
<para>
- Prior to <productname>PostgreSQL</productname> 7.4, the precision in
- <type>float(<replaceable>p</replaceable>)</type> was taken to mean
- so many <emphasis>decimal</> digits. This has been corrected to match the SQL
- standard, which specifies that the precision is measured in binary
- digits. The assumption that <type>real</type> and
+ The assumption that <type>real</type> and
<type>double precision</type> 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
</para>
</note>
- <note>
- <para>
- Prior to <productname>PostgreSQL</productname> 7.3, <type>serial</type>
- implied <literal>UNIQUE</literal>. 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.
- </para>
- </note>
-
<para>
To insert the next value of the sequence into the <type>serial</type>
column, specify that the <type>serial</type>
The SQL standard requires that writing just <type>timestamp</type>
be equivalent to <type>timestamp without time
zone</type>, and <productname>PostgreSQL</productname> honors that
- behavior. (Releases prior to 7.3 treated it as <type>timestamp
- with time zone</type>.) <type>timestamptz</type> is accepted as an
+ behavior. <type>timestamptz</type> is accepted as an
abbreviation for <type>timestamp with time zone</type>; this is a
<productname>PostgreSQL</productname> extension.
</para>
within a single transaction. In practice this limit is not a
problem — note that the limit is on the number of
<acronym>SQL</acronym> commands, not the number of rows processed.
- Also, as of <productname>PostgreSQL</productname> 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.
</para>
</sect1>
</para>
<para>
- In <productname>PostgreSQL</productname> versions before 7.3,
- table names beginning with <literal>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 <literal>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 <literal>make</literal> command line.
</para>
- <caution>
- <para>
- Changing <varname>PG_CONFIG</varname> only works when building
- against <productname>PostgreSQL</productname> 8.3 or later.
- With older releases it does not work to set it to anything except
- <literal>pg_config</>; you must alter your <varname>PATH</>
- to select the installation to build against.
- </para>
- </caution>
-
<para>
You can also run <literal>make</literal> in a directory outside the source
tree of your extension, if you want to keep the build directory separate.
<note>
<para>
- Prior to <productname>PostgreSQL</productname> 8.0, casting an
- integer to <type>bit(n)</> would copy the leftmost <literal>n</>
- bits of the integer, whereas now it copies the rightmost <literal>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 <type>bit(n)</> copies the rightmost
+ <literal>n</> bits. Casting an integer to a bit string width wider
+ than the integer itself will sign-extend on the left.
</para>
</note>
If you disagree with this, please write your complaint to:
Pope, Cathedral Saint-Peter of Roma, Vatican.
</para>
-
- <para>
- <productname>PostgreSQL</productname> releases before 8.0 did not
- follow the conventional numbering of centuries, but just returned
- the year field divided by 100.
- </para>
</listitem>
</varlistentry>
Years in the 1900s are in the second millennium.
The third millennium started January 1, 2001.
</para>
-
- <para>
- <productname>PostgreSQL</productname> releases before 8.0 did not
- follow the conventional numbering of millennia, but just returned
- the year field divided by 1000.
- </para>
</listitem>
</varlistentry>
next <function>nextval</function> will return exactly the specified
value, and sequence advancement commences with the following
<function>nextval</function>. Furthermore, the value reported by
- <function>currval</> is not changed in this case (this is a change
- from pre-8.3 behavior). For example,
+ <function>currval</> is not changed in this case. For example,
<screen>
SELECT setval('foo', 42); <lineannotation>Next <function>nextval</> will return 43</lineannotation>
<literal>PQTRANS_ACTIVE</literal> is reported only when a query
has been sent to the server and not yet completed.
</para>
-
- <caution>
- <para>
- <function>PQtransactionStatus</> will give incorrect results when using
- a <productname>PostgreSQL</> 7.3 server that has the parameter <literal>autocommit</>
- set to off. The server-side autocommit feature has been
- deprecated and does not exist in later server versions.
- </para>
- </caution>
</listitem>
</varlistentry>
WHERE p.locked_row = a.ctid;
</programlisting>
- Be aware however that (as of <productname>PostgreSQL</> 8.3) such a
- query will be very inefficient.
+ Be aware however that such a query will be very inefficient.
</para>
</sect2>
END;
$$ LANGUAGE plpgsql;
</programlisting>
- The other way, which was the only way available before
- <productname>PostgreSQL</productname> 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
<synopsis>
<replaceable>name</replaceable> ALIAS FOR $<replaceable>n</replaceable>;
</tip>
<para>
- As of <productname>PostgreSQL</productname> 7.4, PL/Python is only
- available as an <quote>untrusted</> language, meaning it does not
- offer any way of restricting what users can do in it. It has
- therefore been renamed to <literal>plpythonu</>. The trusted
- variant <literal>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 <quote>untrusted</> language, meaning
+ it does not offer any way of restricting what users can do in it and
+ is therefore named <literal>plpythonu</>. A trusted
+ variant <literal>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.)
</para>
- <para>
- Prior to <productname>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
- <structname>pg_cast</> as well.
- </para>
-
<para>
While not required, it is recommended that you continue to follow this old
convention of naming cast implementation functions after the target data
</para>
<para>
- Prior to <productname>PostgreSQL</productname> 8.0, <command>CREATE
- TABLE AS</command> always included OIDs in the table it
- created. As of <productname>PostgreSQL</productname> 8.0,
- the <command>CREATE TABLE AS</command> command allows the user to
+ The <command>CREATE TABLE AS</command> command allows the user to
explicitly specify whether OIDs should be included. If the
presence of OIDs is not explicitly specified,
the <xref linkend="guc-default-with-oids"> configuration variable is
- used. As of <productname>PostgreSQL</productname> 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 <command>CREATE TABLE
- AS</command> should explicitly specify <literal>WITH (OIDS)</literal>
- to ensure desired behavior.
+ used.
</para>
</refsect1>
<refsect1>
<title>Notes</title>
- <para>
- The option <option>--includedir-server</option> was added in
- <productname>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 <option>--includedir</option>. To make your
- package handle both cases, try the newer option first and test the
- exit status to see whether it succeeded.
- </para>
-
<para>
The options <option>--docdir</option>, <option>--pkgincludedir</option>,
<option>--localedir</option>, <option>--mandir</option>,
The option <option>--htmldir</option> was added in <productname>PostgreSQL</> 8.4.
The option <option>--ldflags_ex</option> was added in <productname>PostgreSQL</> 9.0.
</para>
-
- <para>
- In releases prior to <productname>PostgreSQL</> 7.1, before
- <command>pg_config</command> came to be, a method for finding the
- equivalent configuration information did not exist.
- </para>
</refsect1>
reindex anything.
</para>
- <para>
- Prior to <productname>PostgreSQL</productname> 8.1, <command>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 <command>REINDEX SYSTEM</>.
- </para>
-
- <para>
- Prior to <productname>PostgreSQL</productname> 7.4, <command>REINDEX
- TABLE</> did not automatically process TOAST tables, and so those had
- to be reindexed by separate commands. This is still possible, but
- redundant.
- </para>
</refsect1>
<refsect1>
</para>
<para>
- Prior to <productname>PostgreSQL</> 8.1, the table created by
- <command>SELECT INTO</command> included OIDs by default. In
- <productname>PostgreSQL</productname> 8.1, this is not the case
- — to include OIDs in the new table, the <xref
- linkend="guc-default-with-oids"> configuration variable must be
- enabled. Alternatively, <command>CREATE TABLE AS</command> can be
+ To add OIDs to the table created by <command>SELECT INTO</command>,
+ enable the <xref linkend="guc-default-with-oids"> configuration
+ variable. Alternatively, <command>CREATE TABLE AS</command> can be
used with the <literal>WITH OIDS</literal> clause.
</para>
</refsect1>
</para>
</listitem>
</itemizedlist>
-
- (This system was established in <productname>PostgreSQL</> 7.3.
- In versions before that, the command status might show different
- results when rules exist.)
</para>
<para>
these required items, the cluster configuration files
<filename>postgresql.conf</filename>, <filename>pg_hba.conf</filename>, and
<filename>pg_ident.conf</filename> are traditionally stored in
-<varname>PGDATA</> (although in <productname>PostgreSQL</productname> 8.0 and
-later, it is possible to place them elsewhere).
+<varname>PGDATA</>, although it is possible to place them elsewhere.
</para>
<table tocentry="1" id="pgdata-contents-table">
<note>
<para>
- Before <productname>PostgreSQL</productname> release 8.0, the requirement
- that <literal>STABLE</> and <literal>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 <command>SELECT</>.
+ <productname>PostgreSQL</productname> requires that <literal>STABLE</>
+ and <literal>IMMUTABLE</> functions contain no SQL commands other
+ than <command>SELECT</> to prevent data modification.
(This is not a completely bulletproof test, since such functions could
still call <literal>VOLATILE</> functions that modify the database.
If you do that, you will find that the <literal>STABLE</> or
projects / postgresql / commitdiff