Revision 12442
Added by Aaron Marcuse-Kubitza almost 11 years ago
index.htm | ||
---|---|---|
834 | 834 |
<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;">¶</a> |
835 | 835 |
<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;">¶</a> |
836 | 836 |
<DD>page's description: '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].' |
837 |
<DT><A HREF="http://www.postgresql.org/docs/9.3/interactive/xfunc-volatility.html" name="http://www.postgresql.org/docs/9.3/interactive/xfunc-volatility.html" ADD_DATE="1393355422" 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: Function Volatility Categories ***</A><a name="PostgreSQL: Documentation: 9.3: Function Volatility Categories ***" href="#PostgreSQL: Documentation: 9.3: Function Volatility Categories ***" style="margin-left: 0.5em;">¶</a>
|
|
837 |
<DT><A HREF="http://www.postgresql.org/docs/9.3/interactive/xfunc-volatility.html" name="http://www.postgresql.org/docs/9.3/interactive/xfunc-volatility.html" ADD_DATE="1393355422" 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: Function Volatility Categories **</A><a name="PostgreSQL: Documentation: 9.3: Function Volatility Categories **" href="#PostgreSQL: Documentation: 9.3: Function Volatility Categories **" style="margin-left: 0.5em;">¶</a>
|
|
838 | 838 |
<DD>- |
839 | 839 |
*** "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." |
840 |
this especially includes functions that depend on the search_path! |
|
840 |
this especially includes functions that depend on the search_path! (ie. that lack schema qualifiers on all invoked functions.) however, this effect will only be noticeable if the function is called on only *constant* values in a *PL/pgSQL* function, in which case the wrong search_path (the one in effect at *create* time) will be used.
|
|
841 | 841 |
|
842 | 842 |
** "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)." |
843 | 843 |
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) |
Also available in: Unified diff
web/links/index.htm: updated to Firefox bookmarks: PostgreSQL: difference between STABLE and IMMUTABLE: functions that depend on the search_path: clarified that the confusing effects of using IMMUTABLE for one of these functions are only noticeable if the function is called on only constant values in a PL/pgSQL function (in which case the wrong search_path (the one in effect at create time) will be used)