Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 506183e

Browse files
committed
Be a bit more verbose about the effects of string literal processing
changes in plpgsql. Per bug #4843.
1 parent 156475a commit 506183e

File tree

1 file changed

+9
-1
lines changed

1 file changed

+9
-1
lines changed

doc/src/sgml/release-8.4.sgml

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-8.4.sgml,v 1.8 2009/06/07 20:09:34 tgl Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-8.4.sgml,v 1.9 2009/06/08 14:57:21 tgl Exp $ -->
22
<!-- See header comment in release.sgml about typical markup -->
33

44
<sect1 id="release-8-4">
@@ -2303,6 +2303,14 @@
23032303
Make processing of string literals and nested block comments
23042304
match the main SQL parser's processing (Tom)
23052305
</para>
2306+
2307+
<para>
2308+
In particular, the format string in <command>RAISE</> now works
2309+
the same as any other string literal, including being subject
2310+
to <varname>standard_conforming_strings</>. This change also
2311+
fixes other cases in which valid commands would fail when
2312+
<varname>standard_conforming_strings</> is on.
2313+
</para>
23062314
</listitem>
23072315

23082316
<listitem>

0 commit comments

Comments
 (0)