create your functions, and in another window, use
    <application>psql</application> to load and test those functions.
    If you are doing it this way, it
    is a good idea to write the function using <command>CREATE OR
    REPLACE FUNCTION</command>. That way you can just reload the file to update
    the function definition.  For example:
<programlisting>
CREATE OR REPLACE FUNCTION testfunc(integer) RETURNS integer AS $$
          ....
$$ LANGUAGE plpgsql;
</programlisting>
   </para>

   <para>
    While running <application>psql</application>, you can load or reload such
    a function definition file with:
<programlisting>
\i filename.sql
</programlisting>
    and then immediately issue SQL commands to test the function.
   </para>

   <para>
    Another good way to develop in <application>PL/pgSQL</application> is with a
    GUI database access tool that facilitates development in a
    procedural language. One example of such a tool is
    <application>pgAdmin</application>, although others exist. These tools often
    provide convenient features such as escaping single quotes and
    making it easier to recreate and debug functions.
   </para>

  <sect2 id="plpgsql-quote-tips">
   <title>Handling of Quotation Marks</title>

   <para>
    The code of a <application>PL/pgSQL</application> function is specified in
    <command>CREATE FUNCTION</command> as a string literal.  If you
    write the string literal in the ordinary way with surrounding
    single quotes, then any single quotes inside the function body
    must be doubled; likewise any backslashes must be doubled (assuming
    escape string syntax is used).
    Doubling quotes is at best tedious, and in more complicated cases
    the code can become downright incomprehensible, because you can
    easily find yourself needing half a dozen or more adjacent quote marks.
    It's recommended that you instead write the function body as a
    <quote>dollar-quoted</quote> string literal (see <xref
    linkend="sql-syntax-dollar-quoting"/>).  In the dollar-quoting
    approach, you never double any quote marks, but instead take care to
    choose a different dollar-quoting delimiter for each level of
    nesting you need.  For example, you might write the <command>CREATE
    FUNCTION</command> command as:
<programlisting>
CREATE OR REPLACE FUNCTION testfunc(integer) RETURNS integer AS $PROC$
          ....
$PROC$ LANGUAGE plpgsql;
</programlisting>
    Within this, you might use quote marks for simple literal strings in
    SQL commands and <literal>$$</literal> to delimit fragments of SQL commands
    that you are assembling as strings.  If you need to quote text that
    includes <literal>$$</literal>, you could use <literal>$Q$</literal>, and so on.
   </para>

   <para>
    The following chart shows what you have to do when writing quote
    marks without dollar quoting.  It might be useful when translating
    pre-dollar quoting code into something more comprehensible.
  </para>

  <variablelist>
   <varlistentry id="plpgsql-quote-tips-1-quot">
    <term>1 quotation mark</term>
    <listitem>
     <para>
      To begin and end the function body, for example:
<programlisting>
CREATE FUNCTION foo() RETURNS integer AS '
          ....
' LANGUAGE plpgsql;
</programlisting>
      Anywhere within a single-quoted function body, quote marks
      <emphasis>must</emphasis> appear in pairs.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry id="plpgsql-quote-tips-2-quot">
    <term>2 quotation marks</term>
    <listitem>
     <para>
      For string literals inside the function body, for example:
<programlisting>
a_output := ''Blah'';
SELECT * FROM users WHERE f_name=''foobar'';
</programlisting>
      In the dollar-quoting approach, you'd just write:
<programlisting>
a_output := 'Blah';
SELECT * FROM users WHERE f_name='foobar';
</programlisting>
      which is exactly what the <application>PL/pgSQL</application> parser would see
      in either case.