|
1 |
| -<!-- $PostgreSQL: pgsql/doc/src/sgml/release-9.0.sgml,v 2.14 2010/04/03 07:22:55 petere Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/release-9.0.sgml,v 2.15 2010/04/05 02:46:42 tgl Exp $ --> |
2 | 2 |
|
3 | 3 |
|
4 | 4 | <sect1 id="release-9-0">
|
|
50 | 50 | defaulted to off for many years (Tom Lane)
|
51 | 51 | </para>
|
52 | 52 | </listitem>
|
53 |
| - |
| 53 | + |
54 | 54 | <listitem>
|
55 | 55 | <para>
|
56 | 56 | Remove server variable <varname>regex_flavor</>, which
|
|
59 | 59 | (e.g. Perl-regex compatible) for many years (Tom Lane)
|
60 | 60 | </para>
|
61 | 61 | </listitem>
|
62 |
| - |
| 62 | + |
63 | 63 | </itemizedlist>
|
64 |
| - |
| 64 | + |
65 | 65 | </sect3>
|
66 | 66 |
|
67 | 67 | <sect3>
|
|
97 | 97 |
|
98 | 98 | <listitem>
|
99 | 99 | <para>
|
100 |
| - Fix <link linkend="functions-similarto-regexp"><literal>SIMILAR |
101 |
| - TO</></link> to match the SQL standard-specified behavior |
102 |
| - by processing <literal>?</> and <literal>{}</> the same way |
103 |
| - they are processed in regular expressions (Tom Lane) |
104 |
| - </para> |
105 |
| - </listitem> |
106 |
| - |
107 |
| - <listitem> |
108 |
| - <para> |
109 |
| - Properly treat <literal>^</> and <literal>$</> as literals in |
110 |
| - <literal>SIMILAR TO</> patterns, to match the SQL standard (Tom Lane) |
111 |
| - </para> |
112 |
| - |
113 |
| - <para> |
114 |
| - Previously these were treated using regular expression syntax. This |
115 |
| - change breaks backward compatibility. This also affects |
116 |
| - <function>substring()</>'s interpretation of regular expressions. |
117 |
| - </para> |
118 |
| - </listitem> |
119 |
| - |
120 |
| - <listitem> |
121 |
| - <para> |
122 |
| - Process parentheses as literals in <literal>SIMILAR TO</> expressions; |
123 |
| - also make character class handling more standards-compliant (Tom Lane) |
| 100 | + Improve standards compliance of <link |
| 101 | + linkend="functions-similarto-regexp"><literal>SIMILAR TO</></link> |
| 102 | + patterns and SQL-style <function>substring()</> patterns (Tom Lane) |
124 | 103 | </para>
|
125 | 104 |
|
126 | 105 | <para>
|
127 |
| - This also affects <function>substring()</>'s handling of regular |
128 |
| - expressions. |
| 106 | + This includes treating <literal>?</> and <literal>{...}</> as |
| 107 | + pattern metacharacters, while they were simple literal characters |
| 108 | + before; that corresponds to new features added in SQL:2008. |
| 109 | + Also, <literal>^</> and <literal>$</> are now treated as simple |
| 110 | + literal characters; formerly they were treated as metacharacters, |
| 111 | + as if the pattern were following POSIX rather than SQL rules. |
| 112 | + Also, in SQL-standard <function>substring()</>, use of parentheses |
| 113 | + for nesting no longer interferes with capturing of a substring. |
| 114 | + Also, processing of bracket expressions (character classes) is |
| 115 | + now more standards-compliant. |
129 | 116 | </para>
|
130 | 117 | </listitem>
|
131 | 118 |
|
132 | 119 | <listitem>
|
133 | 120 | <para>
|
134 |
| - Do not allow <link |
135 |
| - linkend="functions-string-sql"><function>substring()</></link> |
136 |
| - to have a negative third length, per the SQL standard (Tom Lane) |
| 121 | + Reject negative length values in 3-parameter <link |
| 122 | + linkend="functions-string-sql"><function>substring()</></link> |
| 123 | + for bit strings, per the SQL standard (Tom Lane) |
137 | 124 | </para>
|
138 | 125 | </listitem>
|
139 | 126 |
|
|
1392 | 1379 |
|
1393 | 1380 | <listitem>
|
1394 | 1381 | <para>
|
1395 |
| - Install server-side language PL/pgSQL by default (Bruce Momjian) |
| 1382 | + Install server-side language PL/pgSQL by default (Bruce Momjian) |
1396 | 1383 | </para>
|
1397 | 1384 | </listitem>
|
1398 | 1385 |
|
|
0 commit comments