mirror of
https://github.com/postgres/postgres.git
synced 2025-05-29 00:03:09 -04:00
Simplify references to backslash-doubling in func.sgml.
Several places were still written as though standard_conforming_strings didn't exist, much less be the default. Now that it is on by default, we can simplify the text and just insert occasional notes suggesting that you might have to think harder if it's turned off. Per discussion of a suggestion from Hannes Frederic Sowa. Back-patch to 9.1 where standard_conforming_strings was made the default.
This commit is contained in:
parent
d6a7271958
commit
a5c1a1969d
@ -3368,8 +3368,8 @@ cast(-44 as bit(12)) <lineannotation>111111010100</lineannotation>
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
<function>LIKE</function> pattern matching always covers the entire
|
<function>LIKE</function> pattern matching always covers the entire
|
||||||
string. Therefore, to match a sequence anywhere within a string, the
|
string. Therefore, if it's desired to match a sequence anywhere within
|
||||||
pattern must start and end with a percent sign.
|
a string, the pattern must start and end with a percent sign.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -3382,17 +3382,13 @@ cast(-44 as bit(12)) <lineannotation>111111010100</lineannotation>
|
|||||||
character itself, write two escape characters.
|
character itself, write two escape characters.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<note>
|
||||||
Note that the backslash already has a special meaning in string literals,
|
<para>
|
||||||
so to write a pattern constant that contains a backslash you must write two
|
If you have <xref linkend="guc-standard-conforming-strings"> turned off,
|
||||||
backslashes in an SQL statement (assuming escape string syntax is used, see
|
any backslashes you write in literal string constants will need to be
|
||||||
<xref linkend="sql-syntax-strings">). Thus, writing a pattern that
|
doubled. See <xref linkend="sql-syntax-strings"> for more information.
|
||||||
actually matches a literal backslash means writing four backslashes in the
|
</para>
|
||||||
statement. You can avoid this by selecting a different escape character
|
</note>
|
||||||
with <literal>ESCAPE</literal>; then a backslash is not special to
|
|
||||||
<function>LIKE</function> anymore. (But backslash is still special to the
|
|
||||||
string literal parser, so you still need two of them to match a backslash.)
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
It's also possible to select no escape character by writing
|
It's also possible to select no escape character by writing
|
||||||
@ -3720,8 +3716,7 @@ substring('foobar' from 'o(.)b') <lineannotation>o</lineannotation>
|
|||||||
inserted, and it can contain <literal>\&</> to indicate that the
|
inserted, and it can contain <literal>\&</> to indicate that the
|
||||||
substring matching the entire pattern should be inserted. Write
|
substring matching the entire pattern should be inserted. Write
|
||||||
<literal>\\</> if you need to put a literal backslash in the replacement
|
<literal>\\</> if you need to put a literal backslash in the replacement
|
||||||
text. (As always, remember to double backslashes written in literal
|
text.
|
||||||
constant strings, assuming escape string syntax is used.)
|
|
||||||
The <replaceable>flags</> parameter is an optional text
|
The <replaceable>flags</> parameter is an optional text
|
||||||
string containing zero or more single-letter flags that change the
|
string containing zero or more single-letter flags that change the
|
||||||
function's behavior. Flag <literal>i</> specifies case-insensitive
|
function's behavior. Flag <literal>i</> specifies case-insensitive
|
||||||
@ -4031,16 +4026,14 @@ SELECT foo FROM regexp_split_to_table('the quick brown fox', E'\\s*') AS foo;
|
|||||||
</table>
|
</table>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
An RE cannot end with <literal>\</>.
|
An RE cannot end with a backslash (<literal>\</>).
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<note>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
Remember that the backslash (<literal>\</literal>) already has a special
|
If you have <xref linkend="guc-standard-conforming-strings"> turned off,
|
||||||
meaning in <productname>PostgreSQL</> string literals.
|
any backslashes you write in literal string constants will need to be
|
||||||
To write a pattern constant that contains a backslash,
|
doubled. See <xref linkend="sql-syntax-strings"> for more information.
|
||||||
you must write two backslashes in the statement, assuming escape
|
|
||||||
string syntax is used (see <xref linkend="sql-syntax-strings">).
|
|
||||||
</para>
|
</para>
|
||||||
</note>
|
</note>
|
||||||
|
|
||||||
@ -5541,10 +5534,8 @@ SELECT SUBSTRING('XY1234Z', 'Y*?([0-9]{1,3})');
|
|||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
If you want to have a double quote in the output you must
|
If you want to have a double quote in the output you must
|
||||||
precede it with a backslash, for example <literal>E'\\"YYYY
|
precede it with a backslash, for example <literal>'\"YYYY
|
||||||
Month\\"'</literal>. <!-- "" font-lock sanity :-) -->
|
Month\"'</literal>. <!-- "" font-lock sanity :-) -->
|
||||||
(Two backslashes are necessary because the backslash
|
|
||||||
has special meaning when using the escape string syntax.)
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user