does not need one if it is followed
    by a meta command).  If you need to create a script file that works with
    both old and new versions of <application>pgbench</application>, be sure to write
    each SQL command on a single line ending with a semicolon.
   </para>
   <para>
    It is assumed that <application>pgbench</application> scripts do not contain
    incomplete blocks of SQL
    transactions. If at runtime the client reaches the end of the script without
    completing the last transaction block, it will be aborted.
   </para>
  </note>

  <para>
   There is a simple variable-substitution facility for script files.
   Variable names must consist of letters (including non-Latin letters),
   digits, and underscores, with the first character not being a digit.
   Variables can be set by the command-line <option>-D</option> option,
   explained above, or by the meta commands explained below.
   In addition to any variables preset by <option>-D</option> command-line options,
   there are a few variables that are preset automatically, listed in
   <xref linkend="pgbench-automatic-variables"/>. A value specified for these
   variables using <option>-D</option> takes precedence over the automatic presets.
   Once set, a variable's
   value can be inserted into an SQL command by writing
   <literal>:</literal><replaceable>variablename</replaceable>.  When running more than
   one client session, each session has its own set of variables.
   <application>pgbench</application> supports up to 255 variable uses in one
   statement.
  </para>

   <table id="pgbench-automatic-variables">
    <title>pgbench Automatic Variables</title>
    <tgroup cols="2">
     <colspec colname="col1" colwidth="1*"/>
     <colspec colname="col2" colwidth="2*"/>
     <thead>
      <row>
       <entry>Variable</entry>
       <entry>Description</entry>
      </row>
     </thead>

     <tbody>
      <row>
       <entry> <literal>client_id</literal> </entry>
       <entry>unique number identifying the client session (starts from zero)</entry>
      </row>

      <row>
       <entry> <literal>default_seed</literal> </entry>
       <entry>seed used in hash and pseudorandom permutation functions by default</entry>
      </row>

      <row>
       <entry> <literal>random_seed</literal> </entry>
       <entry>random generator seed (unless overwritten with <option>-D</option>)</entry>
      </row>

      <row>
       <entry> <literal>scale</literal> </entry>
       <entry>current scale factor</entry>
      </row>
     </tbody>
    </tgroup>
   </table>

  <para>
   Script file meta commands begin with a backslash (<literal>\</literal>) and
   normally extend to the end of the line, although they can be continued
   to additional lines by writing backslash-return.
   Arguments to a meta command are separated by white space.
   These meta commands are supported:
  </para>

  <variablelist>
   <varlistentry id="pgbench-metacommand-gset">
    <term>
     <literal>\gset [<replaceable>prefix</replaceable>]</literal>
     <literal>\aset [<replaceable>prefix</replaceable>]</literal>
    </term>

    <listitem>
     <para>
      These commands may be used to end SQL queries, taking the place of the
      terminating semicolon (<literal>;</literal>).
     </para>

     <para>
      When the <literal>\gset</literal> command is used, the preceding SQL query is
      expected to return one row, the columns of which are stored into variables
      named after column names, and prefixed with <replaceable>prefix</replaceable>
      if provided.
     </para>

     <para>
      When the <literal>\aset</literal> command is used, all combined SQL queries
      (separated by <literal>\;</literal>) have their columns stored into variables
      named after column names, and prefixed with <replaceable>prefix</replaceable>
      if provided. If a query returns no row, no assignment is made and the variable
      can be tested for existence to detect this. If a query returns more