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>
   </para>

   <note>
    <para>
     When you write the argument of such a function as an unadorned
     literal string, it becomes a constant of type <type>regclass</type>
     (or the appropriate type).
     Since this is really just an OID, it will track the originally
     identified object despite later renaming, schema reassignment,
     etc.  This <quote>early binding</quote> behavior is usually desirable for
     object references in column defaults and views.  But sometimes you might
     want <quote>late binding</quote> where the object reference is resolved
     at run time.  To get late-binding behavior, force the constant to be
     stored as a <type>text</type> constant instead of <type>regclass</type>:
<programlisting>
nextval('foo'::text)      <lineannotation><literal>foo</literal> is looked up at runtime</lineannotation>
</programlisting>
     The <function>to_regclass()</function> function and its siblings
     can also be used to perform run-time lookups.  See
     <xref linkend="functions-info-catalog-table"/>.
    </para>
   </note>

   <para>
    Another practical example of use of <type>regclass</type>
    is to look up the OID of a table listed in
    the <literal>information_schema</literal> views, which don't supply
    such OIDs directly.  One might for example wish to call
    the <function>pg_relation_size()</function> function, which requires
    the table OID.  Taking the above rules into account, the correct way
    to do that is
<programlisting>
SELECT table_schema, table_name,
       pg_relation_size((quote_ident(table_schema) || '.' ||
                         quote_ident(table_name))::regclass)
FROM information_schema.tables
WHERE ...
</programlisting>
    The <function>quote_ident()</function> function will take care of
    double-quoting the identifiers where needed.  The seemingly easier
<programlisting>
SELECT pg_relation_size(table_name)
FROM information_schema.tables
WHERE ...
</programlisting>
    is <emphasis>not recommended</emphasis>, because it will fail for
    tables that are outside your search path or have names that require
    quoting.
   </para>

   <para>
    An additional property of most of the OID alias types is the creation of
    dependencies.  If a
    constant of one of these types appears in a stored expression
    (such as a column default expression or view), it creates a dependency
    on the referenced object.  For example, if a column has a default
    expression <literal>nextval('my_seq'::regclass)</literal>,
    <productname>PostgreSQL</productname>
    understands that the default expression depends on the sequence
    <literal>my_seq</literal>, so the system will not let the sequence
    be dropped without first removing the default expression.  The
    alternative of <literal>nextval('my_seq'::text)</literal> does not
    create a dependency.
    (<type>regrole</type> is an exception to this property. Constants of this
    type are not allowed in stored expressions.)
   </para>