|
1 | 1 | <!--
|
2 |
| -$PostgreSQL: pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.236 2009/12/24 23:36:39 tgl Exp $ |
| 2 | +$PostgreSQL: pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.237 2010/01/29 17:44:12 rhaas Exp $ |
3 | 3 | PostgreSQL documentation
|
4 | 4 | -->
|
5 | 5 |
|
@@ -658,7 +658,12 @@ testdb=>
|
658 | 658 | <para>
|
659 | 659 | If an unquoted argument begins with a colon (<literal>:</literal>),
|
660 | 660 | it is taken as a <application>psql</> variable and the value of the
|
661 |
| - variable is used as the argument instead. |
| 661 | + variable is used as the argument instead. If the variable name is |
| 662 | + surrounded by single quotes (e.g. <literal>:'var'</literal>), it |
| 663 | + will be escaped as an SQL literal and the result will be used as |
| 664 | + the argument. If the variable name is surrounded by double quotes, |
| 665 | + it will be escaped as an SQL identifier and the result will be used |
| 666 | + as the argument. |
662 | 667 | </para>
|
663 | 668 |
|
664 | 669 | <para>
|
@@ -2711,59 +2716,62 @@ bar
|
2711 | 2716 | <para>
|
2712 | 2717 | An additional useful feature of <application>psql</application>
|
2713 | 2718 | variables is that you can substitute (<quote>interpolate</quote>)
|
2714 |
| - them into regular <acronym>SQL</acronym> statements. The syntax for |
2715 |
| - this is again to prepend the variable name with a colon |
| 2719 | + them into regular <acronym>SQL</acronym> statements. |
| 2720 | + <application>psql</application> provides special facilities for |
| 2721 | + ensuring that values used as SQL literals and identifiers are |
| 2722 | + properly escaped. The syntax for interpolating a value without |
| 2723 | + any special escaping is again to prepend the variable name with a colon |
2716 | 2724 | (<literal>:</literal>):
|
2717 | 2725 | <programlisting>
|
2718 | 2726 | testdb=> <userinput>\set foo 'my_table'</userinput>
|
2719 | 2727 | testdb=> <userinput>SELECT * FROM :foo;</userinput>
|
2720 | 2728 | </programlisting>
|
2721 |
| - would then query the table <literal>my_table</literal>. The value of |
2722 |
| - the variable is copied literally, so it can even contain unbalanced |
2723 |
| - quotes or backslash commands. You must make sure that it makes sense |
2724 |
| - where you put it. Variable interpolation will not be performed into |
2725 |
| - quoted <acronym>SQL</acronym> entities. |
| 2729 | + would then query the table <literal>my_table</literal>. Note that this |
| 2730 | + may be unsafe: the value of the variable is copied literally, so it can |
| 2731 | + even contain unbalanced quotes or backslash commands. You must make sure |
| 2732 | + that it makes sense where you put it. |
| 2733 | + </para> |
| 2734 | + |
| 2735 | + <para> |
| 2736 | + When a value is to be used as an SQL literal or identifier, it is |
| 2737 | + safest to arrange for it to be escaped. To escape the value of |
| 2738 | + a variable as an SQL literal, write a colon followed by the variable |
| 2739 | + name in single quotes. To escape the value an SQL identifier, write |
| 2740 | + a colon followed by the variable name in double quotes. The previous |
| 2741 | + example would be more safely written this way: |
| 2742 | +<programlisting> |
| 2743 | +testdb=> <userinput>\set foo 'my_table'</userinput> |
| 2744 | +testdb=> <userinput>SELECT * FROM :"foo";</userinput> |
| 2745 | +</programlisting> |
| 2746 | + Variable interpolation will not be performed into quoted |
| 2747 | + <acronym>SQL</acronym> entities. |
2726 | 2748 | </para>
|
2727 | 2749 |
|
2728 | 2750 | <para>
|
2729 | 2751 | One possible use of this mechanism is to
|
2730 | 2752 | copy the contents of a file into a table column. First load the file into a
|
2731 | 2753 | variable and then proceed as above:
|
2732 | 2754 | <programlisting>
|
2733 |
| -testdb=> <userinput>\set content '''' `cat my_file.txt` ''''</userinput> |
2734 |
| -testdb=> <userinput>INSERT INTO my_table VALUES (:content);</userinput> |
2735 |
| -</programlisting> |
2736 |
| - One problem with this approach is that <filename>my_file.txt</filename> |
2737 |
| - might contain single quotes. These need to be escaped so that |
2738 |
| - they don't cause a syntax error when the second line is processed. This |
2739 |
| - could be done with the program <command>sed</command>: |
2740 |
| -<programlisting> |
2741 |
| -testdb=> <userinput>\set content '''' `sed -e "s/'/''/g" < my_file.txt` ''''</userinput> |
2742 |
| -</programlisting> |
2743 |
| - If you are using non-standard-conforming strings then you'll also need |
2744 |
| - to double backslashes. This is a bit tricky: |
2745 |
| -<programlisting> |
2746 |
| -testdb=> <userinput>\set content '''' `sed -e "s/'/''/g" -e 's/\\/\\\\/g' < my_file.txt` ''''</userinput> |
| 2755 | +testdb=> <userinput>\set content `cat my_file.txt`</userinput> |
| 2756 | +testdb=> <userinput>INSERT INTO my_table VALUES (:'content');</userinput> |
2747 | 2757 | </programlisting>
|
2748 |
| - Note the use of different shell quoting conventions so that neither |
2749 |
| - the single quote marks nor the backslashes are special to the shell. |
2750 |
| - Backslashes are still special to <command>sed</command>, however, so |
2751 |
| - we need to double them. (Perhaps |
2752 |
| - at one point you thought it was great that all Unix commands use the |
2753 |
| - same escape character.) |
| 2758 | + (Note that this still won't work if my_file.txt contains NUL bytes. |
| 2759 | + psql does not support embedded NUL bytes in variable values.) |
2754 | 2760 | </para>
|
2755 | 2761 |
|
2756 | 2762 | <para>
|
2757 |
| - Since colons can legally appear in SQL commands, the following rule |
2758 |
| - applies: the character sequence |
2759 |
| - <quote>:name</quote> is not changed unless <quote>name</> is the name |
2760 |
| - of a variable that is currently set. In any case you can escape |
2761 |
| - a colon with a backslash to protect it from substitution. (The |
2762 |
| - colon syntax for variables is standard <acronym>SQL</acronym> for |
| 2763 | + Since colons can legally appear in SQL commands, an apparent attempt |
| 2764 | + at interpolation (such as <literal>:name</literal>, |
| 2765 | + <literal>:'name'</literal>, or <literal>:"name"</literal>) is not |
| 2766 | + changed unless the named variable is currently set. In any case you |
| 2767 | + can escape a colon with a backslash to protect it from substitution. |
| 2768 | + (The colon syntax for variables is standard <acronym>SQL</acronym> for |
2763 | 2769 | embedded query languages, such as <application>ECPG</application>.
|
2764 | 2770 | The colon syntax for array slices and type casts are
|
2765 | 2771 | <productname>PostgreSQL</productname> extensions, hence the
|
2766 |
| - conflict.) |
| 2772 | + conflict. The colon syntax for escaping a variable's value as an |
| 2773 | + SQL literal or identifier is a <application>psql</application> |
| 2774 | + extension.) |
2767 | 2775 | </para>
|
2768 | 2776 |
|
2769 | 2777 | </refsect3>
|
|
0 commit comments