@@ -120,7 +120,7 @@ EXEC SQL CONNECT TO <replaceable>target</replaceable> <optional>AS <replaceable>
120
120
121
121
<listitem>
122
122
<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>
124
124
</simpara>
125
125
</listitem>
126
126
@@ -143,17 +143,26 @@ EXEC SQL CONNECT TO <replaceable>target</replaceable> <optional>AS <replaceable>
143
143
</listitem>
144
144
</itemizedlist>
145
145
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
153
147
to the default database under the default user name. No separate
154
148
user name or connection name can be specified in that case.
155
149
</para>
156
150
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
+
157
166
<para>
158
167
There are also different ways to specify the user name:
159
168
@@ -201,6 +210,15 @@ EXEC SQL CONNECT TO <replaceable>target</replaceable> <optional>AS <replaceable>
201
210
write <literal>&</literal> within a <replaceable>value</replaceable>.
202
211
</para>
203
212
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
+
204
222
<para>
205
223
The <replaceable>connection-name</replaceable> is used to handle
206
224
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>
210
228
chapter).
211
229
</para>
212
230
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
-
225
231
<para>
226
232
Here are some examples of <command>CONNECT</command> statements:
227
233
<programlisting>
228
234
EXEC SQL CONNECT TO mydb@sql.mydomain.com;
229
235
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;
231
237
232
238
EXEC SQL BEGIN DECLARE SECTION;
233
239
const char *target = "mydb@sql.mydomain.com";
@@ -238,8 +244,8 @@ EXEC SQL END DECLARE SECTION;
238
244
EXEC SQL CONNECT TO :target USER :user USING :passwd;
239
245
/* or EXEC SQL CONNECT TO :target USER :user/:passwd; */
240
246
</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
243
249
variables can be used in SQL statements when you prefix them with a
244
250
colon.
245
251
</para>
@@ -251,6 +257,18 @@ EXEC SQL CONNECT TO :target USER :user USING :passwd;
251
257
example above to encapsulate the connection target string
252
258
somewhere.
253
259
</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>
254
272
</sect2>
255
273
256
274
<sect2 id="ecpg-set-connection">
0 commit comments