Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kjCvl-0007C9-0O for pgsql-bugs@arkaria.postgresql.org; Sun, 29 Nov 2020 02:59:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kjCvj-0006QA-F7 for pgsql-bugs@arkaria.postgresql.org; Sun, 29 Nov 2020 02:59:15 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kjCvj-0006Q2-9E for pgsql-bugs@lists.postgresql.org; Sun, 29 Nov 2020 02:59:15 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kjCvc-000354-QJ for pgsql-bugs@lists.postgresql.org; Sun, 29 Nov 2020 02:59:14 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 0AT2x6JT931506; Sat, 28 Nov 2020 21:59:07 -0500 From: Tom Lane To: "David G. Johnston" cc: kgradekx@gmail.com, PostgreSQL mailing lists Subject: Re: BUG #16746: [PG12.5 psql] Password ignored by connect meta-command In-reply-to: <929680.1606616312@sss.pgh.pa.us> References: <16746-44b30e2edf4335d4@postgresql.org> <929680.1606616312@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Sat, 28 Nov 2020 21:18:32 -0500" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <931487.1606618727.0@sss.pgh.pa.us> Date: Sat, 28 Nov 2020 21:59:06 -0500 Message-ID: <931505.1606618746@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <931487.1606618727.1@sss.pgh.pa.us> I wrote: > Ugh... looks like I broke this in 85c54287a et al. I had thought that > this was the pre-existing behavior, but after further study I see that > I was mistaken about how PQconnectdbParams() handles parameter > replacement, so I misread what the prior code was really doing. While I take full responsibility for having messed up here, I note that the documentation for PQconnectdbParams is seriously misleading on the point, in that it fails to point out that parameters appearing after "dbname" will only override the connstring if they supply non-empty values. Besides that, it's rather in need of copy-editing, not to mention some minimal thought about what is a reasonable order to make its points in. So I propose the attached docs fix to begin with. regards, tom lane ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name="fix-PQconnectdbParams-docs.patch"; charset="us-ascii" Content-ID: <931487.1606618727.2@sss.pgh.pa.us> Content-Description: fix-PQconnectdbParams-docs.patch Content-Transfer-Encoding: quoted-printable diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml index 06bd412044..310a886dfb 100644 --- a/doc/src/sgml/libpq.sgml +++ b/doc/src/sgml/libpq.sgml @@ -122,36 +122,52 @@ PGconn *PQconnectdbParams(const char * const *keywor= ds, . = - - When expand_dbname is non-zero, the - dbname key word value is allowed to be reco= gnized - as a connection string. Only the first occurrence of - dbname is expanded this way, any subsequent - dbname value is processed as plain database= name. More - details on the possible connection string formats appear in - . - - The passed arrays can be empty to use all default parameters, or c= an - contain one or more parameter settings. They should be matched in = length. - Processing will stop at the first NULL element + contain one or more parameter settings. They must be matched in le= ngth. + Processing will stop at the first NULL entry in the keywords array. + Also, if the values entry associated with a + non-NULL keywords entry is + NULL or an empty string, that entry is ignored an= d + processing continues with the next pair of array entries. + + + + When expand_dbname is non-zero, the value for + the first dbname key word is checked to see + if it is a connection string. If so, it + is expanded into the individual connection + parameters extracted from the string. Only the first occurrence + of dbname is treated in this way; any + subsequent dbname parameter is processed as + a plain database name. + Details on the possible connection string formats appear in + . = - If any parameter is NULL or an empty string, th= e corresponding - environment variable (see ) is che= cked. - If the environment variable is not set either, then the indicate= d - built-in defaults are used. + In general these arrays are processed from start to end. If any + key word is repeated, the last value (that is + not NULL or empty) is used. This rule applies in + particular when a key word found in a connection string conflicts + with one appearing in the keywords 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 dbname + entry can be overridden by fields of the connection string, and in + turn those fields are overridden by array entries appearing + after dbname (but, again, only if those + entries supply non-empty values). = - In general key words are processed from the beginning of these arr= ays in index - order. The effect of this is that when key words are repeated, the= last processed - value is retained. Therefore, through careful placement of the - dbname key word, it is possible to determin= e what may - be overridden by a conninfo string, and wha= t may not. + After processing all the array entries and any expanded connection + string, any connection parameters that remain unset are filled wit= h + default values. If an unset parameter's corresponding environment + variable (see ) is set, its value = is + used. If the environment variable is not set either, then the + parameter's built-in default value is used. = ------- =_aaaaaaaaaa0--