<entry><structname>pg_operator</structname></entry>
        <entry>operator with argument types</entry>
        <entry><literal>*(integer,&zwsp;integer)</literal>
         or <literal>-(NONE,&zwsp;integer)</literal></entry>
       </row>

       <row>
        <entry><type>regproc</type></entry>
        <entry><structname>pg_proc</structname></entry>
        <entry>function name</entry>
        <entry><literal>sum</literal></entry>
       </row>

       <row>
        <entry><type>regprocedure</type></entry>
        <entry><structname>pg_proc</structname></entry>
        <entry>function with argument types</entry>
        <entry><literal>sum(int4)</literal></entry>
       </row>

       <row>
        <entry><type>regrole</type></entry>
        <entry><structname>pg_authid</structname></entry>
        <entry>role name</entry>
        <entry><literal>smithee</literal></entry>
       </row>

       <row>
        <entry><type>regtype</type></entry>
        <entry><structname>pg_type</structname></entry>
        <entry>data type name</entry>
        <entry><literal>integer</literal></entry>
       </row>
      </tbody>
     </tgroup>
    </table>

   <para>
    All of the OID alias types for objects that are grouped by namespace
    accept schema-qualified names, and will
    display schema-qualified names on output if the object would not
    be found in the current search path without being qualified.
    For example, <literal>myschema.mytable</literal> is acceptable input
    for <type>regclass</type> (if there is such a table).  That value
    might be output as <literal>myschema.mytable</literal>, or
    just <literal>mytable</literal>, depending on the current search path.
    The <type>regproc</type> and <type>regoper</type> alias types will only
    accept input names that are unique (not overloaded), so they are
    of limited use; for most uses <type>regprocedure</type> or
    <type>regoperator</type> are more appropriate.  For <type>regoperator</type>,
    unary operators are identified by writing <literal>NONE</literal> for the unused
    operand.
   </para>

   <para>
    The input functions for these types allow whitespace between tokens,
    and will fold upper-case letters to lower case, except within double
    quotes; this is done to make the syntax rules similar to the way
    object names are written in SQL.  Conversely, the output functions
    will use double quotes if needed to make the output be a valid SQL
    identifier.  For example, the OID of a function
    named <literal>Foo</literal> (with upper case <literal>F</literal>)
    taking two integer arguments could be entered as
    <literal>' "Foo" ( int, integer ) '::regprocedure</literal>.  The
    output would look like <literal>"Foo"(integer,integer)</literal>.
    Both the function name and the argument type names could be
    schema-qualified, too.
   </para>

   <para>
    Many built-in <productname>PostgreSQL</productname> functions accept
    the OID of a table, or another kind of database object, and for
    convenience are declared as taking <type>regclass</type> (or the
    appropriate OID alias type).  This means you do not have to look up
    the object's OID by hand, but can just enter its name as a string
    literal.  For example, the <function>nextval(regclass)</function> function
    takes a sequence relation's OID, so you could call it like this:
<programlisting>
nextval('foo')              <lineannotation>operates on sequence <literal>foo</literal></lineannotation>
nextval('FOO')              <lineannotation>same as above</lineannotation>
nextval('"Foo"')            <lineannotation>operates on sequence <literal>Foo</literal></lineannotation>
nextval('myschema.foo')     <lineannotation>operates on <literal>myschema.foo</literal></lineannotation>
nextval('"myschema".foo')   <lineannotation>same as above</lineannotation>
nextval('foo')              <lineannotation>searches search path for <literal>foo</literal></lineannotation>
</programlisting>