Revision 12636
Added by Aaron Marcuse-Kubitza almost 11 years ago
web/links/index.htm: updated to Firefox bookmarks: PostgreSQL: query planner: documented that incorrect query plans are an ongoing bug in Postgres, because it does not support index hints and by default does not follow the join order. specifically, Postgres often does the following things in query plans which should normally never be done:
- performs a sequential scan when an index is available (because it incorrectly thinks there are too many dead rows in the index)
- uses an in-memory hash join when an index is available (because it incorrectly thinks that accessing an index on disk will be too slow)
- sorts both input tables before performing a merge join (if really no index is available, a hash join is much faster than two sorts and a merge join)
- does joins in the opposite order that they should be done (because it incorrectly thinks that the last table in the join will be filtered to fewer rows than the first table, and ignores the programmer's join order)
| trunk/web/links/index.htm | ||
|---|---|---|
| 729 | 729 |
</DL><p> |
| 730 | 730 |
<DT><a name="doc" href="#doc"><H3 ADD_DATE="1366152313">doc</H3></a> |
| 731 | 731 |
<DL><p> |
| 732 |
<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> |
|
| 733 |
<DD>- |
|
| 734 |
*** "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." |
|
| 735 |
this especially includes functions that depend on the search_path! (ie. that don't have 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. |
|
| 736 |
|
|
| 737 |
** "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)." |
|
| 738 |
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) |
|
| 739 |
<DT><A HREF="http://www.postgresql.org/docs/9.3/static/explicit-joins.html" name="http://www.postgresql.org/docs/9.3/static/explicit-joins.html" ADD_DATE="1394188171" 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: Controlling the Planner with Explicit JOIN Clauses</A><a name="*** PostgreSQL: Documentation: 9.3: Controlling the Planner with Explicit JOIN Clauses" href="#*** PostgreSQL: Documentation: 9.3: Controlling the Planner with Explicit JOIN Clauses" style="margin-left: 0.5em;">¶</a> |
|
| 740 |
<DT><A HREF="http://www.postgresql.org/docs/9.3/static/runtime-config-query.html" name="http://www.postgresql.org/docs/9.3/static/runtime-config-query.html" ADD_DATE="1394182959" 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: Query Planning</A><a name="**** PostgreSQL: Documentation: 9.3: Query Planning" href="#**** PostgreSQL: Documentation: 9.3: Query Planning" style="margin-left: 0.5em;">¶</a> |
|
| 741 |
<DD>- |
|
| 742 |
**** "join_collapse_limit (integer) |
|
| 743 |
|
|
| 744 |
The planner will rewrite explicit JOIN constructs (except FULL JOINs) into lists of FROM items whenever a list of no more than this many items would result. Smaller values reduce planning time but might yield inferior query plans." |
|
| 745 |
you definitely want to turn this *off* in all cases! joins are written in a particular order for a reason (because the programmer knows which indexes are available and therefore which order is correct). the query planner is not smarter than the programmer! |
|
| 746 |
|
|
| 747 |
incorrect query plans are an ongoing bug in Postgres, because it does not support index hints and by default does not follow the join order. specifically, Postgres often does the following things in query plans which should normally never be done: |
|
| 748 |
* performs a sequential scan when an index is available (because it incorrectly thinks there are too many dead rows in the index) |
|
| 749 |
* uses an in-memory hash join when an index is available (because it incorrectly thinks that accessing an index on disk will be too slow) |
|
| 750 |
* sorts *both* input tables before performing a merge join (if really no index is available, a hash join is much faster than two sorts and a merge join) |
|
| 751 |
* does joins in the opposite order that they should be done (because it incorrectly thinks that the last table in the join will be filtered to fewer rows than the first table, and ignores the programmer's join order) |
|
| 732 | 752 |
<DT><A HREF="http://www.postgresql.org/docs/8.3/static/functions-array.html" name="http://www.postgresql.org/docs/8.3/static/functions-array.html" ADD_DATE="1345012706" 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: 8.3: Array Functions and Operators</A><a name="PostgreSQL: Documentation: 8.3: Array Functions and Operators" href="#PostgreSQL: Documentation: 8.3: Array Functions and Operators" style="margin-left: 0.5em;">¶</a> |
| 733 | 753 |
<DT><A HREF="http://www.postgresql.org/docs/8.3/static/plpgsql-control-structures.html" name="http://www.postgresql.org/docs/8.3/static/plpgsql-control-structures.html" ADD_DATE="1342742575" 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: 8.3: Control Structures</A><a name="PostgreSQL: Documentation: 8.3: Control Structures" href="#PostgreSQL: Documentation: 8.3: Control Structures" style="margin-left: 0.5em;">¶</a> |
| 734 | 754 |
<DT><A HREF="http://www.postgresql.org/docs/8.3/static/catalog-pg-enum.html" name="http://www.postgresql.org/docs/8.3/static/catalog-pg-enum.html" ADD_DATE="1349409516" 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: 8.3: pg_enum</A><a name="PostgreSQL: Documentation: 8.3: pg_enum" href="#PostgreSQL: Documentation: 8.3: pg_enum" style="margin-left: 0.5em;">¶</a> |
| ... | ... | |
| 870 | 890 |
there is unfortunately *no* option to do this in pgAdmin |
| 871 | 891 |
<DT><A HREF="http://www.postgresql.org/docs/9.3/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN" name="http://www.postgresql.org/docs/9.3/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN" ADD_DATE="1393518205" 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: 18.8.2. When To Log</A><a name="PostgreSQL: Documentation: 9.3: Error Reporting and Logging: 18.8.2. When To Log" href="#PostgreSQL: Documentation: 9.3: Error Reporting and Logging: 18.8.2. When To Log" style="margin-left: 0.5em;">¶</a> |
| 872 | 892 |
<DD>"client_min_messages [...] Valid values are DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG, NOTICE, WARNING, ERROR, FATAL, and PANIC. Each level includes all the levels that follow it." |
| 873 |
<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> |
|
| 874 |
<DD>- |
|
| 875 |
*** "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." |
|
| 876 |
this especially includes functions that depend on the search_path! (ie. that don't have 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. |
|
| 877 |
|
|
| 878 |
** "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)." |
|
| 879 |
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) |
|
| 880 | 893 |
<DT><A HREF="http://www.postgresql.org/docs/9.3/static/functions-geometry.html" name="http://www.postgresql.org/docs/9.3/static/functions-geometry.html" ADD_DATE="1393319486" 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: Geometric Functions and Operators</A><a name="PostgreSQL: Documentation: 9.3: Geometric Functions and Operators" href="#PostgreSQL: Documentation: 9.3: Geometric Functions and Operators" style="margin-left: 0.5em;">¶</a> |
| 881 | 894 |
<DT><A HREF="http://www.postgresql.org/docs/9.3/static/functions-matching.html#POSIX-MATCHING-RULES" name="http://www.postgresql.org/docs/9.3/static/functions-matching.html#POSIX-MATCHING-RULES" ADD_DATE="1393381432" 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: Pattern Matching: 9.7.3.5. Regular Expression Matching Rules</A><a name="PostgreSQL: Documentation: 9.3: Pattern Matching: 9.7.3.5. Regular Expression Matching Rules" href="#PostgreSQL: Documentation: 9.3: Pattern Matching: 9.7.3.5. Regular Expression Matching Rules" style="margin-left: 0.5em;">¶</a> |
| 882 | 895 |
<DD>"If newline-sensitive matching is specified, . and bracket expressions using ^ will never match the newline character (so that matches will never cross newlines unless the RE explicitly arranges it) and ^ and $ will match the empty string after and before a newline respectively" |
| ... | ... | |
| 894 | 907 |
<DD>"For some types of errors, the server reports the name of a database object (a table, table column, data type, or constraint) associated with the error; for example, the name of the unique constraint that caused a unique_violation error. Such names are supplied in separate fields of the error report message so that applications need not try to extract them from the possibly-localized human-readable text of the message. As of PostgreSQL 9.3, complete coverage for this feature exists only for errors in SQLSTATE class 23 (integrity constraint violation), but this is likely to be expanded in future." |
| 895 | 908 |
this is especially useful for error parsing in column-based import [wiki.vegpath.org/Column-based_import] (and may even have been motivated by it!) |
| 896 | 909 |
<DT><A HREF="http://www.postgresql.org/docs/9.3/static/app-psql.html#APP-PSQL-PATTERNS" name="http://www.postgresql.org/docs/9.3/static/app-psql.html#APP-PSQL-PATTERNS" ADD_DATE="1392338475" 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: psql</A><a name="PostgreSQL: Documentation: 9.3: psql" href="#PostgreSQL: Documentation: 9.3: psql" style="margin-left: 0.5em;">¶</a> |
| 897 |
<DT><A HREF="http://www.postgresql.org/docs/9.3/static/runtime-config-query.html" name="http://www.postgresql.org/docs/9.3/static/runtime-config-query.html" ADD_DATE="1394182959" 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: Query Planning ****</A><a name="PostgreSQL: Documentation: 9.3: Query Planning ****" href="#PostgreSQL: Documentation: 9.3: Query Planning ****" style="margin-left: 0.5em;">¶</a> |
|
| 898 |
<DD>- |
|
| 899 |
**** "join_collapse_limit (integer) |
|
| 900 |
|
|
| 901 |
The planner will rewrite explicit JOIN constructs (except FULL JOINs) into lists of FROM items whenever a list of no more than this many items would result. Smaller values reduce planning time but might yield inferior query plans." |
|
| 902 |
you definitely want to turn this *off* in all cases! joins are written in a particular order for a reason (because the programmer knows which indexes are available and therefore which order is correct). the query planner is not smarter than the programmer! |
|
| 903 | 910 |
<DT><A HREF="http://www.postgresql.org/docs/9.3/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST" name="http://www.postgresql.org/docs/9.3/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST" ADD_DATE="1394165454" 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: Resource Consumption: 18.4.4. Cost-based Vacuum Delay</A><a name="PostgreSQL: Documentation: 9.3: Resource Consumption: 18.4.4. Cost-based Vacuum Delay" href="#PostgreSQL: Documentation: 9.3: Resource Consumption: 18.4.4. Cost-based Vacuum Delay" style="margin-left: 0.5em;">¶</a> |
| 904 | 911 |
<DD>"During the execution of VACUUM and ANALYZE commands, the system maintains an internal counter that keeps track of the estimated cost of the various I/O operations that are performed. When the accumulated cost reaches a limit (specified by vacuum_cost_limit), the process performing the operation will sleep for a short period of time, as specified by vacuum_cost_delay. Then it will reset the counter and continue execution." |
| 905 | 912 |
|
| ... | ... | |
| 1445 | 1452 |
</DL><p> |
| 1446 | 1453 |
<DT><a name="vs. other SQL DBs" href="#vs. other SQL DBs"><H3 ADD_DATE="1366900069">vs. other SQL DBs</H3></a> |
| 1447 | 1454 |
<DL><p> |
| 1455 |
<DT><A HREF="https://www.odesk.com/blog/2009/06/postgresql-vs-mysql/" name="https://www.odesk.com/blog/2009/06/postgresql-vs-mysql/" ADD_DATE="1394189973" ICON_URI="https://www.odesk.com/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="https://www.odesk.com/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL vs. MySQL: A Comparison of Speed, Integrity and Popularity » oBlog</A><a name="PostgreSQL vs. MySQL: A Comparison of Speed, Integrity and Popularity » oBlog" href="#PostgreSQL vs. MySQL: A Comparison of Speed, Integrity and Popularity » oBlog" style="margin-left: 0.5em;">¶</a> |
|
| 1456 |
<DD>"MySQL is still the world's most popular open source database, with over 50,000 downloads per day. Its accessible attitude fostered high popularity and rapid growth of the MySQL community" |
|
| 1448 | 1457 |
<DT><A HREF="http://grimoire.ca/mysql/choose-something-else" name="http://grimoire.ca/mysql/choose-something-else" ADD_DATE="1366900045" LAST_CHARSET="UTF-8"><img width="16" height="16" src="blank.gif" style="margin-right: 0.5em;"/>The Codex » Do Not Pass This Way Again</A><a name="The Codex » Do Not Pass This Way Again" href="#The Codex » Do Not Pass This Way Again" style="margin-left: 0.5em;">¶</a> |
| 1449 | 1458 |
<DD>- |
| 1450 | 1459 |
arguments for MySQL: |
| ... | ... | |
| 1525 | 1534 |
http://www.alphaworks.ibm.com/tech/db2uriaccess |
| 1526 | 1535 |
" |
| 1527 | 1536 |
</DL><p> |
| 1528 |
<DT><A HREF="http://en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL" name="http://en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL" ADD_DATE="1393552874" ICON_URI="http://en.wikipedia.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://en.wikipedia.org/favicon.ico" style="margin-right: 0.5em;"/>Hierarchical and recursive queries in SQL - Wikipedia, the free encyclopedia</A><a name="Hierarchical and recursive queries in SQL - Wikipedia, the free encyclopedia" href="#Hierarchical and recursive queries in SQL - Wikipedia, the free encyclopedia" style="margin-left: 0.5em;">¶</a>
|
|
| 1537 |
<DT><A HREF="http://en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL" name="http://en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL" ADD_DATE="1393552874" ICON_URI="http://bits.wikimedia.org/favicon/wikipedia.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://bits.wikimedia.org/favicon/wikipedia.ico" style="margin-right: 0.5em;"/>Hierarchical and recursive queries in SQL - Wikipedia, the free encyclopedia</A><a name="Hierarchical and recursive queries in SQL - Wikipedia, the free encyclopedia" href="#Hierarchical and recursive queries in SQL - Wikipedia, the free encyclopedia" style="margin-left: 0.5em;">¶</a>
|
|
| 1529 | 1538 |
<DD>"Recursive CTEs (or "recursive subquery factoring"[15] in Oracle lingo) can be used to traverse relations (as graphs or trees)" |
| 1539 |
|
|
| 1540 |
recursive queries function like queues: the 2nd half (after UNION ALL) fetches its input from the next row at the beginning of the queue, and appends its result row(s) to the end of the queue |
|
| 1530 | 1541 |
</DL><p> |
| 1531 | 1542 |
<DT><A HREF="http://en.wikipedia.org/wiki/Object-relational_database" name="http://en.wikipedia.org/wiki/Object-relational_database" ADD_DATE="1367483651" ICON_URI="http://bits.wikimedia.org/favicon/wikipedia.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://bits.wikimedia.org/favicon/wikipedia.ico" style="margin-right: 0.5em;"/>Object-relational database - Wikipedia, the free encyclopedia</A><a name="Object-relational database - Wikipedia, the free encyclopedia" href="#Object-relational database - Wikipedia, the free encyclopedia" style="margin-left: 0.5em;">¶</a> |
| 1532 | 1543 |
</DL><p> |
| ... | ... | |
| 1550 | 1561 |
|
| 1551 | 1562 |
"CPUBoss recommends the Intel Core i5 3570K based on its performance, single-core performance and overclocking." |
| 1552 | 1563 |
</DL><p> |
| 1564 |
<DT><A HREF="http://compnetworking.about.com/od/wirelessinternet/g/bldef_wimax.htm" name="http://compnetworking.about.com/od/wirelessinternet/g/bldef_wimax.htm" ADD_DATE="1394237214" ICON_URI="http://0.tqn.com/f/a.ico" LAST_CHARSET="windows-1252"><img width="16" height="16" src="http://0.tqn.com/f/a.ico" style="margin-right: 0.5em;"/>What Is WiMAX Broadband Wireless Networking?</A><a name="What Is WiMAX Broadband Wireless Networking?" href="#What Is WiMAX Broadband Wireless Networking?" style="margin-left: 0.5em;">¶</a> |
|
| 1565 |
<DD>page's own description: WiMAX is the industry term for standard network technologies supporting long-distance wireless broadband. The WiMAX standard provides both fixed and mobile wireless connectivity options. |
|
| 1566 |
<DT><A HREF="http://compnetworking.about.com/cs/wireless80211/a/aa80211standard.htm" name="http://compnetworking.about.com/cs/wireless80211/a/aa80211standard.htm" ADD_DATE="1394237028" ICON_URI="http://0.tqn.com/f/a.ico" LAST_CHARSET="windows-1252"><img width="16" height="16" src="http://0.tqn.com/f/a.ico" style="margin-right: 0.5em;"/>Wireless Standards - 802.11a, 802.11b/g/n and 802.11ac - Which Is Best?</A><a name="Wireless Standards - 802.11a, 802.11b/g/n and 802.11ac - Which Is Best?" href="#Wireless Standards - 802.11a, 802.11b/g/n and 802.11ac - Which Is Best?" style="margin-left: 0.5em;">¶</a> |
|
| 1567 |
<DD>page's own description: Which of the popular wireless home networking standards like 802.11n or 802.11ac Wi-Fi is right for you? This article explains the pros and cons of each of these wireless standards. |
|
| 1553 | 1568 |
</DL><p> |
| 1554 | 1569 |
<DT><a name="LDAP" href="#LDAP"><H3 ADD_DATE="1360708326">LDAP</H3></a> |
| 1555 | 1570 |
<DL><p> |
| ... | ... | |
| 2809 | 2824 |
<DD>page's own description: Free HTML XHTML CSS JavaScript jQuery XML DOM XSL XSLT RSS AJAX ASP .NET PHP SQL tutorials, references, examples for web building. |
| 2810 | 2825 |
</DL><p> |
| 2811 | 2826 |
<DT><A HREF="https://www.google.com/search?q=%s" name="https://www.google.com/search?q=%s" ADD_DATE="1318464507" ICON_URI="https://www.google.com/favicon.ico" SHORTCUTURL="g"><img width="16" height="16" src="https://www.google.com/favicon.ico" style="margin-right: 0.5em;"/>Google</A><a name="Google" href="#Google" style="margin-left: 0.5em;">¶</a> |
| 2812 |
<DT><A HREF="https://www.google.com/calendar/render" name="https://www.google.com/calendar/render" ADD_DATE="1318014776" ICON_URI="https://calendar.google.com/googlecalendar/images/favicon_v2013_6.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="https://calendar.google.com/googlecalendar/images/favicon_v2013_6.ico" style="margin-right: 0.5em;"/>Google Calendar</A><a name="Google Calendar" href="#Google Calendar" style="margin-left: 0.5em;">¶</a>
|
|
| 2827 |
<DT><A HREF="https://www.google.com/calendar/render" name="https://www.google.com/calendar/render" ADD_DATE="1318014776" ICON_URI="https://calendar.google.com/googlecalendar/images/favicon_v2013_7.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="https://calendar.google.com/googlecalendar/images/favicon_v2013_7.ico" style="margin-right: 0.5em;"/>Google Calendar</A><a name="Google Calendar" href="#Google Calendar" style="margin-left: 0.5em;">¶</a>
|
|
| 2813 | 2828 |
<DT><A HREF="javascript:(function(){var%20ca,cea,cs,df,dfe,i,j,x,y;function%20n(i,what){return%20i+%22%20%22+what+((i==1)?%22%22:%22s%22)}ca=cea=cs=0;df=document.forms;for(i=0;i<df.length;++i){x=df[i];dfe=x.elements;if(x.onsubmit){x.onsubmit=%22%22;++cs;}if(x.attributes[%22autocomplete%22]){x.attributes[%22autocomplete%22].value=%22on%22;++ca;}for(j=0;j<dfe.length;++j){y=dfe[j];if(y.attributes[%22autocomplete%22]){y.attributes[%22autocomplete%22].value=%22on%22;++cea;}}}alert(%22Removed%20autocomplete=off%20from%20%22+n(ca,%22form%22)+%22%20and%20from%20%22+n(cea,%22form%20element%22)+%22,%20and%20removed%20onsubmit%20from%20%22+n(cs,%22form%22)+%22.%20After%20you%20type%20your%20password%20and%20submit%20the%20form,%20the%20browser%20will%20offer%20to%20remember%20your%20password.%22)})();" name="javascript:(function(){var%20ca,cea,cs,df,dfe,i,j,x,y;function%20n(i,what){return%20i+%22%20%22+what+((i==1)?%22%22:%22s%22)}ca=cea=cs=0;df=document.forms;for(i=0;i<df.length;++i){x=df[i];dfe=x.elements;if(x.onsubmit){x.onsubmit=%22%22;++cs;}if(x.attributes[%22autocomplete%22]){x.attributes[%22autocomplete%22].value=%22on%22;++ca;}for(j=0;j<dfe.length;++j){y=dfe[j];if(y.attributes[%22autocomplete%22]){y.attributes[%22autocomplete%22].value=%22on%22;++cea;}}}alert(%22Removed%20autocomplete=off%20from%20%22+n(ca,%22form%22)+%22%20and%20from%20%22+n(cea,%22form%20element%22)+%22,%20and%20removed%20onsubmit%20from%20%22+n(cs,%22form%22)+%22.%20After%20you%20type%20your%20password%20and%20submit%20the%20form,%20the%20browser%20will%20offer%20to%20remember%20your%20password.%22)})();" ADD_DATE="1318292619" SHORTCUTURL="r"><img width="16" height="16" src="blank.gif" style="margin-right: 0.5em;"/>remember password</A><a name="remember password" href="#remember password" style="margin-left: 0.5em;">¶</a>
|
| 2814 | 2829 |
<HR> <DT><A HREF="place:sort=14&type=6&maxResults=10&queryType=1" name="place:sort=14&type=6&maxResults=10&queryType=1"><img width="16" height="16" src="blank.gif" style="margin-right: 0.5em;"/>Recent Tags</A><a name="Recent Tags" href="#Recent Tags" style="margin-left: 0.5em;">¶</a> |
| 2815 | 2830 |
<DT><A HREF="place:folder=BOOKMARKS_MENU&folder=UNFILED_BOOKMARKS&folder=TOOLBAR&sort=12&excludeQueries=1&maxResults=10&queryType=1" name="place:folder=BOOKMARKS_MENU&folder=UNFILED_BOOKMARKS&folder=TOOLBAR&sort=12&excludeQueries=1&maxResults=10&queryType=1"><img width="16" height="16" src="blank.gif" style="margin-right: 0.5em;"/>Recently Bookmarked</A><a name="Recently Bookmarked" href="#Recently Bookmarked" style="margin-left: 0.5em;">¶</a> |
Also available in: Unified diff