</para>

<para>

In order to function, this module must be loaded via

In order to function, this module must be loaded via

<xref linkend="guc-shared-preload-libraries"> in <filename>postgresql.conf</>.

</para>

t

(1 row)

</programlisting>

because <literal>postgres</> gets stemmed to <literal>postgr</>:

because <literal>postgres</> gets stemmed to <literal>postgr</>:

<programlisting>

SELECT to_tsquery('postgres:*');

to_tsquery

<literal>pg_stat_replication</></link> view. Large differences between

<function>pg_current_xlog_location</> and <literal>sent_location</> field

might indicate that the master server is under heavy load, while

differences between <literal>sent_location</> and

differences between <literal>sent_location</> and

<function>pg_last_xlog_receive_location</> on the standby might indicate

network delay, or that the standby is under heavy load.

</para>

<xref linkend="installation-notes-mingw"> and <xref linkend="installation-notes-cygwin">.

To produce native 64 bit binaries in these environments, use the tools from

<productname>MinGW-w64</productname>. These tools can also be used to

cross-compile for 32 bit and 64 bit <productname>Windows</productname>

targets on other hosts, such as <productname>Linux</productname> and

cross-compile for 32 bit and 64 bit <productname>Windows</productname>

targets on other hosts, such as <productname>Linux</productname> and

<productname>Darwin</productname>.

<productname>Cygwin</productname> is not recommended for running a

production server, and it should only be used for running on

</para>

<para>

Native builds of <application>psql</application> don't support command

Native builds of <application>psql</application> don't support command

line editing. The <productname>Cygwin</productname> build does support

command line editing, so it should be used where psql is needed for

interactive use on <productname>Windows</productname>.

<application>pg_upgrade</> requires the specification of the old and new cluster's

data and executable (<filename>bin</>) directories. You can also specify

user and port values, and whether you want the data linked instead of

copied (the default).

copied (the default).

</para>

<para>

DROP FOREIGN TABLE [ IF EXISTS ] <replaceable class="PARAMETER">name</replaceable> [, ...] [ CASCADE | RESTRICT ]

</synopsis>

</refsynopsisdiv>

<refsect1>

<title>Description</title>

Only the owner of a foreign table can remove it.

</para>

</refsect1>

<refsect1>

<title>Parameters</title>

<title>Examples</title>

<para>

To destroy two foreign tables, <literal>films</literal> and

To destroy two foreign tables, <literal>films</literal> and

<literal>distributors</literal>:

<programlisting>

DROP FOREIGN TABLE films, distributors;

</programlisting></para>

</refsect1>

<refsect1>

<title>Compatibility</title>

<para>

Note that the single-user mode server does not provide sophisticated

line-editing features (no command history, for example).

line-editing features (no command history, for example).

Single-User mode also does not do any background processing, like

automatic checkpoints.

Second, build and install the policy package for the regression test.

The <filename>sepgsql-regtest.pp</> is a special purpose policy package

which provides a set of rules to be allowed during the regression tests.

It should be built from the policy source file

It should be built from the policy source file

(<filename>sepgsql-regtest.te</>), which is normally done using

<command>make</command>. You will need to locate the appropriate

Makefile on your system; the path shown below is only an example.