@@ -120,7 +120,7 @@ EXEC SQL CONNECT TO <replaceable>target</replaceable> <optional>AS <replaceable>
120120
121121 <listitem>
122122 <simpara>
123- <literal>unix:postgresql://<replaceable>hostname</replaceable> <optional>:<replaceable>port</replaceable></optional><optional>/<replaceable>dbname</replaceable></optional><optional>?<replaceable>options</replaceable></optional></literal>
123+ <literal>unix:postgresql://localhost <optional>:<replaceable>port</replaceable></optional><optional>/<replaceable>dbname</replaceable></optional><optional>?<replaceable>options</replaceable></optional></literal>
124124 </simpara>
125125 </listitem>
126126
@@ -143,17 +143,26 @@ EXEC SQL CONNECT TO <replaceable>target</replaceable> <optional>AS <replaceable>
143143 </listitem>
144144 </itemizedlist>
145145
146- If you specify the connection target literally (that is, not
147- through a variable reference) and you don't quote the value, then
148- the case-insensitivity rules of normal SQL are applied. In that
149- case you can also double-quote the individual parameters separately
150- as needed. In practice, it is probably less error-prone to use a
151- (single-quoted) string literal or a variable reference. The
152- connection target <literal>DEFAULT</literal> initiates a connection
146+ The connection target <literal>DEFAULT</literal> initiates a connection
153147 to the default database under the default user name. No separate
154148 user name or connection name can be specified in that case.
155149 </para>
156150
151+ <para>
152+ If you specify the connection target directly (that is, not as a string
153+ literal or variable reference), then the components of the target are
154+ passed through normal SQL parsing; this means that, for example,
155+ the <replaceable>hostname</replaceable> must look like one or more SQL
156+ identifiers separated by dots, and those identifiers will be
157+ case-folded unless double-quoted. Values of
158+ any <replaceable>options</replaceable> must be SQL identifiers,
159+ integers, or variable references. Of course, you can put nearly
160+ anything into an SQL identifier by double-quoting it.
161+ In practice, it is probably less error-prone to use a (single-quoted)
162+ string literal or a variable reference than to write the connection
163+ target directly.
164+ </para>
165+
157166 <para>
158167 There are also different ways to specify the user name:
159168
@@ -201,6 +210,15 @@ EXEC SQL CONNECT TO <replaceable>target</replaceable> <optional>AS <replaceable>
201210 write <literal>&</literal> within a <replaceable>value</replaceable>.
202211 </para>
203212
213+ <para>
214+ Notice that when specifying a socket connection
215+ (with the <literal>unix:</literal> prefix), the host name must be
216+ exactly <literal>localhost</literal>. To select a non-default
217+ socket directory, write the directory's pathname as the value of
218+ a <varname>host</varname> option in
219+ the <replaceable>options</replaceable> part of the target.
220+ </para>
221+
204222 <para>
205223 The <replaceable>connection-name</replaceable> is used to handle
206224 multiple connections in one program. It can be omitted if a
@@ -210,24 +228,12 @@ EXEC SQL CONNECT TO <replaceable>target</replaceable> <optional>AS <replaceable>
210228 chapter).
211229 </para>
212230
213- <para>
214- If untrusted users have access to a database that has not adopted a
215- <link linkend="ddl-schemas-patterns">secure schema usage pattern</link>,
216- begin each session by removing publicly-writable schemas
217- from <varname>search_path</varname>. For example,
218- add <literal>options=-c search_path=</literal>
219- to <literal><replaceable>options</replaceable></literal>, or
220- issue <literal>EXEC SQL SELECT pg_catalog.set_config('search_path', '',
221- false);</literal> after connecting. This consideration is not specific to
222- ECPG; it applies to every interface for executing arbitrary SQL commands.
223- </para>
224-
225231 <para>
226232 Here are some examples of <command>CONNECT</command> statements:
227233<programlisting>
228234EXEC SQL CONNECT TO mydb@sql.mydomain.com;
229235
230- EXEC SQL CONNECT TO unix :postgresql://sql.mydomain.com/mydb AS myconnection USER john;
236+ EXEC SQL CONNECT TO tcp :postgresql://sql.mydomain.com/mydb AS myconnection USER john;
231237
232238EXEC SQL BEGIN DECLARE SECTION;
233239const char *target = "mydb@sql.mydomain.com";
@@ -238,8 +244,8 @@ EXEC SQL END DECLARE SECTION;
238244EXEC SQL CONNECT TO :target USER :user USING :passwd;
239245/* or EXEC SQL CONNECT TO :target USER :user/:passwd; */
240246</programlisting>
241- The last form makes use of the variant referred to above as
242- character variable reference . You will see in later sections how C
247+ The last example makes use of the feature referred to above as
248+ character variable references . You will see in later sections how C
243249 variables can be used in SQL statements when you prefix them with a
244250 colon.
245251 </para>
@@ -251,6 +257,18 @@ EXEC SQL CONNECT TO :target USER :user USING :passwd;
251257 example above to encapsulate the connection target string
252258 somewhere.
253259 </para>
260+
261+ <para>
262+ If untrusted users have access to a database that has not adopted a
263+ <link linkend="ddl-schemas-patterns">secure schema usage pattern</link>,
264+ begin each session by removing publicly-writable schemas
265+ from <varname>search_path</varname>. For example,
266+ add <literal>options=-c search_path=</literal>
267+ to <literal><replaceable>options</replaceable></literal>, or
268+ issue <literal>EXEC SQL SELECT pg_catalog.set_config('search_path', '',
269+ false);</literal> after connecting. This consideration is not specific to
270+ ECPG; it applies to every interface for executing arbitrary SQL commands.
271+ </para>
254272 </sect2>
255273
256274 <sect2 id="ecpg-set-connection">
0 commit comments