<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.114 2008/02/13 22:44:06 momjian Exp $ -->

<para>

In practice you probably want to test your client applications on the

new version before switching over completely. This is another reason

for setting up concurrent installations of old and new versions. When

testing a <productname>PostgreSQL</> major upgrade, consider the

following categories of possible changes:

</para>

<variablelist>

<varlistentry>

<term>Administration</term>

<listitem>

<para>

The capabilities available for administrators to monitor and control

the server often change and improve in each major release.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term>SQL</term>

<listitem>

<para>

Typically this includes new SQL command capabilities and not changes

in behavior, unless specifically mentioned in the release notes.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term>Library API</term>

<listitem>

<para>

Typically libraries like <application>libpq</> only add new

functionality, again unless mentioned in the release notes.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term>System Catalogs</term>

<listitem>

<para>

System catalog changes usually only affect database management tools.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term>Server C-language API</term>

<listitem>

<para>

This involved changes in the backend function API, which is written

in the C programming language. Such changes effect code that

references backend functions deep inside the server.

</para>

</listitem>

</varlistentry>

</variablelist>