aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-10-22 18:29:40 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2020-10-22 18:29:46 -0400
commitc16a1bbcf498f0aa053a3e55008f57d7f67357dd (patch)
treeb2fd1aa32bfe49c2f40ebc6a5df1ae079b8dbf4b /doc/src
parent3dfb1942d9b8748b93094a430289e2f7f3b3ae0d (diff)
downloadpostgresql-c16a1bbcf498f0aa053a3e55008f57d7f67357dd.tar.gz
postgresql-c16a1bbcf498f0aa053a3e55008f57d7f67357dd.zip
Add documentation and tests for quote marks in ECPG literal queries.
ECPG's PREPARE ... FROM and EXECUTE IMMEDIATE can optionally take the target query as a simple literal, rather than the more usual string-variable reference. This was previously documented as being a C string literal, but that's a lie in one critical respect: you can't write a data double quote as \" in such literals. That's because the lexer is in SQL mode at this point, so it'll parse double-quoted strings as SQL identifiers, within which backslash is not special, so \" ends the literal. I looked into making this work as documented, but getting the lexer to switch behaviors at just the right point is somewhere between very difficult and impossible. It's not really worth the trouble, because these cases are next to useless: if you have a fixed SQL statement to execute or prepare, you might as well write it as a direct EXEC SQL, saving the messiness of converting it into a string literal and gaining the opportunity for compile-time SQL syntax checking. Instead, let's just document (and test) the workaround of writing a double quote as an octal escape (\042) in such cases. There's no code behavioral change here, so in principle this could be back-patched, but it's such a niche case I doubt it's worth the trouble. Per report from 1250kv. Discussion: https://postgr.es/m/673825.1603223178@sss.pgh.pa.us
Diffstat (limited to 'doc/src')
-rw-r--r--doc/src/sgml/ecpg.sgml59
1 files changed, 54 insertions, 5 deletions
diff --git a/doc/src/sgml/ecpg.sgml b/doc/src/sgml/ecpg.sgml
index 419574e9ea6..14dcbdb4e32 100644
--- a/doc/src/sgml/ecpg.sgml
+++ b/doc/src/sgml/ecpg.sgml
@@ -7066,7 +7066,7 @@ EXECUTE IMMEDIATE <replaceable class="parameter">string</replaceable>
<term><replaceable class="parameter">string</replaceable></term>
<listitem>
<para>
- A literal C string or a host variable containing the SQL
+ A literal string or a host variable containing the SQL
statement to be executed.
</para>
</listitem>
@@ -7075,6 +7075,30 @@ EXECUTE IMMEDIATE <replaceable class="parameter">string</replaceable>
</refsect1>
<refsect1>
+ <title>Notes</title>
+
+ <para>
+ In typical usage, the <replaceable>string</replaceable> is a host
+ variable reference to a string containing a dynamically-constructed
+ SQL statement. The case of a literal string is not very useful;
+ you might as well just write the SQL statement directly, without
+ the extra typing of <command>EXECUTE IMMEDIATE</command>.
+ </para>
+
+ <para>
+ If you do use a literal string, keep in mind that any double quotes
+ you might wish to include in the SQL statement must be written as
+ octal escapes (<literal>\042</literal>) not the usual C
+ idiom <literal>\"</literal>. This is because the string is inside
+ an <literal>EXEC SQL</literal> section, so the ECPG lexer parses it
+ according to SQL rules not C rules. Any embedded backslashes will
+ later be handled according to C rules; but <literal>\"</literal>
+ causes an immediate syntax error because it is seen as ending the
+ literal.
+ </para>
+ </refsect1>
+
+ <refsect1>
<title>Examples</title>
<para>
@@ -7388,7 +7412,7 @@ EXEC SQL OPEN :curname1;
<refsynopsisdiv>
<synopsis>
-PREPARE <replaceable class="parameter">name</replaceable> FROM <replaceable class="parameter">string</replaceable>
+PREPARE <replaceable class="parameter">prepared_name</replaceable> FROM <replaceable class="parameter">string</replaceable>
</synopsis>
</refsynopsisdiv>
@@ -7421,9 +7445,10 @@ PREPARE <replaceable class="parameter">name</replaceable> FROM <replaceable clas
<term><replaceable class="parameter">string</replaceable></term>
<listitem>
<para>
- A literal C string or a host variable containing a preparable
- statement, one of the SELECT, INSERT, UPDATE, or
- DELETE.
+ A literal string or a host variable containing a preparable
+ SQL statement, one of SELECT, INSERT, UPDATE, or DELETE.
+ Use question marks (<literal>?</literal>) for parameter values
+ to be supplied at execution.
</para>
</listitem>
</varlistentry>
@@ -7431,6 +7456,30 @@ PREPARE <replaceable class="parameter">name</replaceable> FROM <replaceable clas
</refsect1>
<refsect1>
+ <title>Notes</title>
+
+ <para>
+ In typical usage, the <replaceable>string</replaceable> is a host
+ variable reference to a string containing a dynamically-constructed
+ SQL statement. The case of a literal string is not very useful;
+ you might as well just write a direct SQL <command>PREPARE</command>
+ statement.
+ </para>
+
+ <para>
+ If you do use a literal string, keep in mind that any double quotes
+ you might wish to include in the SQL statement must be written as
+ octal escapes (<literal>\042</literal>) not the usual C
+ idiom <literal>\"</literal>. This is because the string is inside
+ an <literal>EXEC SQL</literal> section, so the ECPG lexer parses it
+ according to SQL rules not C rules. Any embedded backslashes will
+ later be handled according to C rules; but <literal>\"</literal>
+ causes an immediate syntax error because it is seen as ending the
+ literal.
+ </para>
+ </refsect1>
+
+ <refsect1>
<title>Examples</title>
<programlisting>
char *stmt = "SELECT * FROM test1 WHERE a = ? AND b = ?";