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

Commit db83c04

Browse files
committed
Doc: clarify behavior of PQconnectdbParams().
The documentation omitted the critical tidbit that a keyword-array entry is simply ignored if its corresponding value-array entry is NULL or an empty string; it will *not* override any previously-obtained value for the parameter. (See conninfo_array_parse().) I'd supposed that would force the setting back to default, which is what led me into bug #16746; but it doesn't. While here, I couldn't resist the temptation to do some copy-editing, both in the description of PQconnectdbParams() and in the section about connection URI syntax. Discussion: https://postgr.es/m/931505.1606618746@sss.pgh.pa.us
1 parent 7b5b90b commit db83c04

File tree

1 file changed

+57
-44
lines changed

1 file changed

+57
-44
lines changed

doc/src/sgml/libpq.sgml

Lines changed: 57 additions & 44 deletions
Original file line numberDiff line numberDiff line change
@@ -123,35 +123,53 @@ PGconn *PQconnectdbParams(const char * const *keywords,
123123
</para>
124124

125125
<para>
126-
When <literal>expand_dbname</literal> is non-zero, the
127-
<parameter>dbname</parameter> key word value is allowed to be recognized
128-
as a connection string. Only the first occurrence of
129-
<parameter>dbname</parameter> is expanded this way, any subsequent
130-
<parameter>dbname</parameter> value is processed as plain database name. More
131-
details on the possible connection string formats appear in
132-
<xref linkend="libpq-connstring"/>.
126+
The passed arrays can be empty to use all default parameters, or can
127+
contain one or more parameter settings. They must be matched in length.
128+
Processing will stop at the first <symbol>NULL</symbol> entry
129+
in the <literal>keywords</literal> array.
130+
Also, if the <literal>values</literal> entry associated with a
131+
non-<symbol>NULL</symbol> <literal>keywords</literal> entry is
132+
<symbol>NULL</symbol> or an empty string, that entry is ignored and
133+
processing continues with the next pair of array entries.
133134
</para>
134135

135136
<para>
136-
The passed arrays can be empty to use all default parameters, or can
137-
contain one or more parameter settings. They should be matched in length.
138-
Processing will stop at the first <symbol>NULL</symbol> element
139-
in the <literal>keywords</literal> array.
137+
When <literal>expand_dbname</literal> is non-zero, the value for
138+
the first <parameter>dbname</parameter> key word is checked to see
139+
if it is a <firstterm>connection string</firstterm>. If so, it
140+
is <quote>expanded</quote> into the individual connection
141+
parameters extracted from the string. The value is considered to
142+
be a connection string, rather than just a database name, if it
143+
contains an equal sign (<literal>=</literal>) or it begins with a
144+
URI scheme designator. (More details on connection string formats
145+
appear in <xref linkend="libpq-connstring"/>.) Only the first
146+
occurrence of <parameter>dbname</parameter> is treated in this way;
147+
any subsequent <parameter>dbname</parameter> parameter is processed
148+
as a plain database name.
140149
</para>
141150

142151
<para>
143-
If any parameter is <symbol>NULL</symbol> or an empty string, the corresponding
144-
environment variable (see <xref linkend="libpq-envars"/>) is checked.
145-
If the environment variable is not set either, then the indicated
146-
built-in defaults are used.
152+
In general the parameter arrays are processed from start to end.
153+
If any key word is repeated, the last value (that is
154+
not <symbol>NULL</symbol> or empty) is used. This rule applies in
155+
particular when a key word found in a connection string conflicts
156+
with one appearing in the <literal>keywords</literal> array. Thus,
157+
the programmer may determine whether array entries can override or
158+
be overridden by values taken from a connection string. Array
159+
entries appearing before an expanded <parameter>dbname</parameter>
160+
entry can be overridden by fields of the connection string, and in
161+
turn those fields are overridden by array entries appearing
162+
after <parameter>dbname</parameter> (but, again, only if those
163+
entries supply non-empty values).
147164
</para>
148165

149166
<para>
150-
In general key words are processed from the beginning of these arrays in index
151-
order. The effect of this is that when key words are repeated, the last processed
152-
value is retained. Therefore, through careful placement of the
153-
<parameter>dbname</parameter> key word, it is possible to determine what may
154-
be overridden by a <parameter>conninfo</parameter> string, and what may not.
167+
After processing all the array entries and any expanded connection
168+
string, any connection parameters that remain unset are filled with
169+
default values. If an unset parameter's corresponding environment
170+
variable (see <xref linkend="libpq-envars"/>) is set, its value is
171+
used. If the environment variable is not set either, then the
172+
parameter's built-in default value is used.
155173
</para>
156174

157175
</listitem>
@@ -817,15 +835,15 @@ host=localhost port=5432 dbname=mydb connect_timeout=10
817835
<para>
818836
The general form for a connection <acronym>URI</acronym> is:
819837
<synopsis>
820-
postgresql://[user[:password]@][netloc][:port][,...][/dbname][?param1=value1&amp;...]
838+
postgresql://[user[:password]@][host][:port][,...][/dbname][?param1=value1&amp;...]
821839
</synopsis>
822840
</para>
823841

824842
<para>
825843
The <acronym>URI</acronym> scheme designator can be either
826844
<literal>postgresql://</literal> or <literal>postgres://</literal>. Each
827-
of the <acronym>URI</acronym> parts is optional. The following examples
828-
illustrate valid <acronym>URI</acronym> syntax uses:
845+
of the remaining <acronym>URI</acronym> parts is optional. The
846+
following examples illustrate valid <acronym>URI</acronym> syntax:
829847
<programlisting>
830848
postgresql://
831849
postgresql://localhost
@@ -836,11 +854,17 @@ postgresql://user:secret@localhost
836854
postgresql://other@localhost/otherdb?connect_timeout=10&amp;application_name=myapp
837855
postgresql://host1:123,host2:456/somedb?target_session_attrs=any&amp;application_name=myapp
838856
</programlisting>
839-
Components of the hierarchical part of the <acronym>URI</acronym> can also
840-
be given as parameters. For example:
857+
Values that would normally appear in the hierarchical part of
858+
the <acronym>URI</acronym> can alternatively be given as named
859+
parameters. For example:
841860
<programlisting>
842861
postgresql:///mydb?host=localhost&amp;port=5433
843862
</programlisting>
863+
All named parameters must match key words listed in
864+
<xref linkend="libpq-paramkeywords"/>, except that for compatibility
865+
with JDBC connection <acronym>URI</acronym>s, instances
866+
of <literal>ssl=true</literal> are translated into
867+
<literal>sslmode=require</literal>.
844868
</para>
845869

846870
<para>
@@ -851,34 +875,23 @@ postgresql:///mydb?host=localhost&amp;port=5433
851875
</para>
852876

853877
<para>
854-
Any connection parameters not corresponding to key words listed in <xref
855-
linkend="libpq-paramkeywords"/> are ignored and a warning message about them
856-
is sent to <filename>stderr</filename>.
857-
</para>
858-
859-
<para>
860-
For improved compatibility with JDBC connection <acronym>URI</acronym>s,
861-
instances of parameter <literal>ssl=true</literal> are translated into
862-
<literal>sslmode=require</literal>.
863-
</para>
864-
865-
<para>
866-
The host part may be either host name or an IP address. To specify an
867-
IPv6 host address, enclose it in square brackets:
878+
The host part may be either a host name or an IP address. To specify an
879+
IPv6 address, enclose it in square brackets:
868880
<synopsis>
869881
postgresql://[2001:db8::1234]/database
870882
</synopsis>
871883
</para>
872884

873885
<para>
874-
The host component is interpreted as described for the parameter <xref
886+
The host part is interpreted as described for the parameter <xref
875887
linkend="libpq-connect-host"/>. In particular, a Unix-domain socket
876-
connection is chosen if the host part is either empty or starts with a
877-
slash, otherwise a TCP/IP connection is initiated. Note, however, that the
888+
connection is chosen if the host part is either empty or looks like an
889+
absolute path name,
890+
otherwise a TCP/IP connection is initiated. Note, however, that the
878891
slash is a reserved character in the hierarchical part of the URI. So, to
879892
specify a non-standard Unix-domain socket directory, either omit the host
880-
specification in the URI and specify the host as a parameter, or
881-
percent-encode the path in the host component of the URI:
893+
part of the URI and specify the host as a named parameter, or
894+
percent-encode the path in the host part of the URI:
882895
<programlisting>
883896
postgresql:///dbname?host=/var/lib/postgresql
884897
postgresql://%2Fvar%2Flib%2Fpostgresql/dbname

0 commit comments

Comments
 (0)