<DT><A HREF="http://www.postgresql.org/docs/9.3/static/sql-createdomain.html" name="http://www.postgresql.org/docs/9.3/static/sql-createdomain.html" ADD_DATE="1386257057" ICON_URI="http://www.postgresql.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://www.postgresql.org/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL: Documentation: 9.3: CREATE DOMAIN</A><a name="PostgreSQL: Documentation: 9.3: CREATE DOMAIN" href="#PostgreSQL: Documentation: 9.3: CREATE DOMAIN" style="margin-left: 0.5em;">&para;</a>

                                <DT><A HREF="http://www.postgresql.org/docs/9.3/static/runtime-config-logging.html#GUC-LOG-ERROR-VERBOSITY" name="http://www.postgresql.org/docs/9.3/static/runtime-config-logging.html#GUC-LOG-ERROR-VERBOSITY" ADD_DATE="1384823719" ICON_URI="http://www.postgresql.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://www.postgresql.org/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL: Documentation: 9.3: Error Reporting and Logging</A><a name="PostgreSQL: Documentation: 9.3: Error Reporting and Logging" href="#PostgreSQL: Documentation: 9.3: Error Reporting and Logging" style="margin-left: 0.5em;">&para;</a>

<DD>page's description: &#39;Valid values are TERSE, DEFAULT, and VERBOSE, each adding more fields to displayed messages. TERSE excludes the logging of DETAIL, HINT, QUERY, and CONTEXT error information. VERBOSE output includes the SQLSTATE error code (see also Appendix A) and the source code file name, function name, and line number that generated the error. Only superusers can change this setting [but it also exists in psql].&#39;

<DD>-

*** "A common error is to label a function IMMUTABLE when its results depend on a configuration parameter. For example, a function that manipulates timestamps might well have results that depend on the TimeZone setting. For safety, such functions should be labeled STABLE instead."

** "There is relatively little difference between STABLE and IMMUTABLE categories when considering simple interactive queries that are planned and immediately executed: it doesn't matter a lot whether a function is executed once during planning or once during query execution startup. But there is a big difference if the plan is saved and reused later. Labeling a function IMMUTABLE when it really isn't might allow it to be prematurely folded to a constant during planning, resulting in a stale value being re-used during subsequent uses of the plan. This is a hazard when using prepared statements or when using function languages that cache plans (such as PL/pgSQL)."

ie. if you are going to use your STABLE function in a PL/pgSQL function, be sure to label it STABLE so that it does not get constant-folded until call time (if labeled IMMUTABLE, it would be folded right away when the function is created)