Commit d5e2bdf7 authored by Tom Lane's avatar Tom Lane

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
parent 0f89ca08
...@@ -123,35 +123,53 @@ PGconn *PQconnectdbParams(const char * const *keywords, ...@@ -123,35 +123,53 @@ PGconn *PQconnectdbParams(const char * const *keywords,
</para> </para>
<para> <para>
When <literal>expand_dbname</literal> is non-zero, the The passed arrays can be empty to use all default parameters, or can
<parameter>dbname</parameter> key word value is allowed to be recognized contain one or more parameter settings. They must be matched in length.
as a connection string. Only the first occurrence of Processing will stop at the first <symbol>NULL</symbol> entry
<parameter>dbname</parameter> is expanded this way, any subsequent in the <literal>keywords</literal> array.
<parameter>dbname</parameter> value is processed as plain database name. More Also, if the <literal>values</literal> entry associated with a
details on the possible connection string formats appear in non-<symbol>NULL</symbol> <literal>keywords</literal> entry is
<xref linkend="libpq-connstring"/>. <symbol>NULL</symbol> or an empty string, that entry is ignored and
processing continues with the next pair of array entries.
</para> </para>
<para> <para>
The passed arrays can be empty to use all default parameters, or can When <literal>expand_dbname</literal> is non-zero, the value for
contain one or more parameter settings. They should be matched in length. the first <parameter>dbname</parameter> key word is checked to see
Processing will stop at the first <symbol>NULL</symbol> element if it is a <firstterm>connection string</firstterm>. If so, it
in the <literal>keywords</literal> array. is <quote>expanded</quote> into the individual connection
parameters extracted from the string. The value is considered to
be a connection string, rather than just a database name, if it
contains an equal sign (<literal>=</literal>) or it begins with a
URI scheme designator. (More details on connection string formats
appear in <xref linkend="libpq-connstring"/>.) Only the first
occurrence of <parameter>dbname</parameter> is treated in this way;
any subsequent <parameter>dbname</parameter> parameter is processed
as a plain database name.
</para> </para>
<para> <para>
If any parameter is <symbol>NULL</symbol> or an empty string, the corresponding In general the parameter arrays are processed from start to end.
environment variable (see <xref linkend="libpq-envars"/>) is checked. If any key word is repeated, the last value (that is
If the environment variable is not set either, then the indicated not <symbol>NULL</symbol> or empty) is used. This rule applies in
built-in defaults are used. particular when a key word found in a connection string conflicts
with one appearing in the <literal>keywords</literal> array. Thus,
the programmer may determine whether array entries can override or
be overridden by values taken from a connection string. Array
entries appearing before an expanded <parameter>dbname</parameter>
entry can be overridden by fields of the connection string, and in
turn those fields are overridden by array entries appearing
after <parameter>dbname</parameter> (but, again, only if those
entries supply non-empty values).
</para> </para>
<para> <para>
In general key words are processed from the beginning of these arrays in index After processing all the array entries and any expanded connection
order. The effect of this is that when key words are repeated, the last processed string, any connection parameters that remain unset are filled with
value is retained. Therefore, through careful placement of the default values. If an unset parameter's corresponding environment
<parameter>dbname</parameter> key word, it is possible to determine what may variable (see <xref linkend="libpq-envars"/>) is set, its value is
be overridden by a <parameter>conninfo</parameter> string, and what may not. used. If the environment variable is not set either, then the
parameter's built-in default value is used.
</para> </para>
</listitem> </listitem>
...@@ -887,15 +905,15 @@ host=localhost port=5432 dbname=mydb connect_timeout=10 ...@@ -887,15 +905,15 @@ host=localhost port=5432 dbname=mydb connect_timeout=10
<para> <para>
The general form for a connection <acronym>URI</acronym> is: The general form for a connection <acronym>URI</acronym> is:
<synopsis> <synopsis>
postgresql://[user[:password]@][netloc][:port][,...][/dbname][?param1=value1&amp;...] postgresql://[user[:password]@][host][:port][,...][/dbname][?param1=value1&amp;...]
</synopsis> </synopsis>
</para> </para>
<para> <para>
The <acronym>URI</acronym> scheme designator can be either The <acronym>URI</acronym> scheme designator can be either
<literal>postgresql://</literal> or <literal>postgres://</literal>. Each <literal>postgresql://</literal> or <literal>postgres://</literal>. Each
of the <acronym>URI</acronym> parts is optional. The following examples of the remaining <acronym>URI</acronym> parts is optional. The
illustrate valid <acronym>URI</acronym> syntax uses: following examples illustrate valid <acronym>URI</acronym> syntax:
<programlisting> <programlisting>
postgresql:// postgresql://
postgresql://localhost postgresql://localhost
...@@ -906,11 +924,17 @@ postgresql://user:secret@localhost ...@@ -906,11 +924,17 @@ postgresql://user:secret@localhost
postgresql://other@localhost/otherdb?connect_timeout=10&amp;application_name=myapp postgresql://other@localhost/otherdb?connect_timeout=10&amp;application_name=myapp
postgresql://host1:123,host2:456/somedb?target_session_attrs=any&amp;application_name=myapp postgresql://host1:123,host2:456/somedb?target_session_attrs=any&amp;application_name=myapp
</programlisting> </programlisting>
Components of the hierarchical part of the <acronym>URI</acronym> can also Values that would normally appear in the hierarchical part of
be given as parameters. For example: the <acronym>URI</acronym> can alternatively be given as named
parameters. For example:
<programlisting> <programlisting>
postgresql:///mydb?host=localhost&amp;port=5433 postgresql:///mydb?host=localhost&amp;port=5433
</programlisting> </programlisting>
All named parameters must match key words listed in
<xref linkend="libpq-paramkeywords"/>, except that for compatibility
with JDBC connection <acronym>URI</acronym>s, instances
of <literal>ssl=true</literal> are translated into
<literal>sslmode=require</literal>.
</para> </para>
<para> <para>
...@@ -926,35 +950,23 @@ postgresql://user@localhost:5433/mydb?options=-c%20synchronous_commit%3Doff ...@@ -926,35 +950,23 @@ postgresql://user@localhost:5433/mydb?options=-c%20synchronous_commit%3Doff
</para> </para>
<para> <para>
Any connection parameters not corresponding to key words listed in <xref The host part may be either a host name or an IP address. To specify an
linkend="libpq-paramkeywords"/> are ignored and a warning message about them IPv6 address, enclose it in square brackets:
is sent to <filename>stderr</filename>.
</para>
<para>
For improved compatibility with JDBC connection <acronym>URI</acronym>s,
instances of parameter <literal>ssl=true</literal> are translated into
<literal>sslmode=require</literal>.
</para>
<para>
The host part may be either host name or an IP address. To specify an
IPv6 host address, enclose it in square brackets:
<synopsis> <synopsis>
postgresql://[2001:db8::1234]/database postgresql://[2001:db8::1234]/database
</synopsis> </synopsis>
</para> </para>
<para> <para>
The host component is interpreted as described for the parameter <xref The host part is interpreted as described for the parameter <xref
linkend="libpq-connect-host"/>. In particular, a Unix-domain socket linkend="libpq-connect-host"/>. In particular, a Unix-domain socket
connection is chosen if the host part is either empty or looks like an connection is chosen if the host part is either empty or looks like an
absolute path name, absolute path name,
otherwise a TCP/IP connection is initiated. Note, however, that the otherwise a TCP/IP connection is initiated. Note, however, that the
slash is a reserved character in the hierarchical part of the URI. So, to slash is a reserved character in the hierarchical part of the URI. So, to
specify a non-standard Unix-domain socket directory, either omit the host specify a non-standard Unix-domain socket directory, either omit the host
specification in the URI and specify the host as a parameter, or part of the URI and specify the host as a named parameter, or
percent-encode the path in the host component of the URI: percent-encode the path in the host part of the URI:
<programlisting> <programlisting>
postgresql:///dbname?host=/var/lib/postgresql postgresql:///dbname?host=/var/lib/postgresql
postgresql://%2Fvar%2Flib%2Fpostgresql/dbname postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment