<!--  -->

<refentry id="slonik">
<refmeta>
    <refentrytitle id="app-slonik-title"><application>slonik</application></refentrytitle>
    <manvolnum>1</manvolnum>
    <refmiscinfo>Application</refmiscinfo>
  </refmeta>

  <refnamediv>
    <refname><application>slonik</application></refname>
    <refpurpose>
      &slony1; command processor
    </refpurpose>
  </refnamediv>

 <indexterm zone="slonik">
  <primary>slonik</primary>
 </indexterm>

 <refsynopsisdiv>
  <cmdsynopsis>
   <command>slonik</command>
   <arg><replaceable class="parameter">options</replaceable></arg>
   <arg><replaceable class="parameter">filename</replaceable></arg>
  </cmdsynopsis>
 </refsynopsisdiv>
<refsect1>
  <title>Options</title>
  <variablelist>
	<varlistentry>
	  <term><option>-w</option></term>
	  <listitem>
		<para>
		  Suppress slonik's behaviour of automatically waiting
		  for event confirmations before submitting events to
		  a different node. If this option is specified, your
		  slonik script may require explicit <xref
		  linkend="stmtwaitevent"> commands in order to behave
		  properly, as was the behaviour of slonik prior to
		  version 2.1.
		  </para>
		</listitem>
	  </varlistentry>
	</variablelist>
  </refsect1>
 <refsect1>
  <title>Description</title>

    <para>
     <application>slonik</application> is the command processor
     application that is used to set up and modify configurations of
     &slony1; replication clusters.
    </para>
 </refsect1>

 <refsect1><title>Outline</title>

  <para>The <application>slonik</application> command line utility is
  supposed to be used embedded into shell scripts; it reads commands
  from files or stdin.</para>

  <para>It reads a set of Slonik statements, which are written in a
  scripting language with syntax similar to that of SQL, and performs
  the set of configuration changes on the slony nodes specified in the
  script.</para>

  <para>Nearly all of the real configuration work is actually done by
  calling stored procedures after loading the
  <productname>Slony-I</productname> support base into a database.
  <application>Slonik</application> was created because these stored
  procedures have special requirements as to on which particular node
  in the replication system they are called.  The absence of named
  parameters for stored procedures makes it rather hard to do this
  from the <application>psql</application> prompt, and
  <application>psql</application> lacks the ability to maintain
  multiple connections with open transactions to multiple
  databases.</para>

  <para>The format of the Slonik <quote>language</quote> is very
  similar to that of SQL, and the parser is based on a similar set of
  formatting rules for such things as numbers and strings.  Note that
  slonik is declarative, using literal values throughout.  It is
  anticipated that Slonik scripts will typically be
  <emphasis>generated</emphasis> by scripts, such as Bash or Perl, and
  these sorts of scripting languages already have perfectly good ways
  of managing variables, doing iteration, and such.</para>
  
  <para>See also <link linkend="slonikref"> Slonik Command Language
  reference </link>. </para>

 </refsect1>

 <refsect1>
  <title>Exit Status</title>

  <para>
   <application>slonik</application> returns 0 to the shell if it
   finished normally.  Scripts may specify return codes.   
  </para>
 </refsect1>
</refentry>

<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:"slony.sgml"
sgml-exposed-tags:nil
sgml-local-catalogs:"/usr/lib/sgml/catalog"
sgml-local-ecat-files:nil
End:
-->
