From: Grigorev Jurij <ju.grigorev@ftdata.ru>
To: Diego <mrstephenamell@gmail.com>
CC: Denis Smirnov <darthunix@gmail.com>, Jacob Champion
	<jacob.champion@enterprisedb.com>, "pgsql-hackers@lists.postgresql.org"
	<pgsql-hackers@lists.postgresql.org>
Subject: Re: [PATCH] libpq: Add PQpassfileLookup()
Thread-Topic: [PATCH] libpq: Add PQpassfileLookup()
Thread-Index: AQIqvYvk14BeS9hVPUmteHfaeDijmLYn+LdggALFngCABTUTWQ==
Date: Sat, 12 Sep 2026 13:26:36 +0000
Message-ID: <8b93e9c7642b47b49d5b287ed032b00a@localhost.localdomain>
References: <b650e555-11c7-415d-8bda-c747c492ab4a@gmail.com>
 <56a73ea31de54ebea53877367cdd6abf@localhost.localdomain>,<00e741a7-8dc1-4993-87f4-8976e9c3b6ba@gmail.com>
In-Reply-To: <00e741a7-8dc1-4993-87f4-8976e9c3b6ba@gmail.com>
Accept-Language: ru-RU, en-US
Content-Language: ru-RU
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/8b93e9c7642b47b49d5b287ed032b00a%40localhost.localdomain>
Precedence: bulk

Hi Diego,

Thanks for the updated patch.  I went through v2 and confirmed that all
the points from my previous review have been addressed.  CI is green,
the implementation, tests, and API boundary look good to me, and I
found no further issues.

Noticed one small wording issue in both the commit message and the
documentation.  They say that PGPASSFILE is the only environment
variable consulted by PQpassfileLookup().  Strictly speaking, when the
default password file location is used, pqGetHomeDirectory() consults
HOME on Unix.  The new TAP test relies on this behavior as well.

Perhaps this could instead say:

    Other libpq connection-parameter environment variables are not
    applied to the lookup keys; in particular, PGHOST and PGPORT are
    ignored.

This is only a documentation wording issue; the implementation is
correct.  With that adjusted, the patch looks ready for committer review
from my side.  Since this introduces a new public libpq API, additional
opinions on the API are of course welcome.

Best regards,
  Yuriy Grigoryev
________________________________________
=EF=D4: Diego <mrstephenamell@gmail.com>
=EF=D4=D0=D2=C1=D7=CC=C5=CE=CF: 9 =D3=C5=CE=D4=D1=C2=D2=D1 2026 =C7. 19:33:=
16
=EB=CF=CD=D5: =E7=D2=C9=C7=CF=D2=D8=C5=D7 =E0=D2=C9=CA
=EB=CF=D0=C9=D1: Denis Smirnov; Jacob Champion; pgsql-hackers@lists.postgre=
sql.org
=F4=C5=CD=C1: Re: [PATCH] libpq: Add PQpassfileLookup()

Hi Jurij,

Thanks for the great review! v2 attached: all your points addressed,
plus a rebase onto current master.

 > I think the simplest option is to keep the proposed public signature
 > and document that NULL is returned if no matching password is found or
 > if the lookup cannot be completed, for example because of an allocation
 > failure.  Alternatively, the public API would need an error output
 > parameter.

Done the simple way: the docs and the function's comment now say NULL
means no matching password was found or the lookup could not be
completed.  I also took your other suggestion and made
passwordFromFile() accept a NULL error pointer, so the wrapper no
longer needs a dummy variable.

 > There is no need to copy the environment value here.  passfile can
 > point directly to pgpassenv; the local buffer is needed only when
 > constructing the default path.

Done exactly that way, the truncation is gone.

 >   * NULL and empty port should use DEF_PGPORT_STR.  The current
 >     localhost test uses a wildcard port, so it does not test that
 >     default.  The test should account for a non-standard compiled-in
 >     port rather than assuming 5432.

Added.  The test client grew a --passfile-defaults mode that prints
DEF_PGPORT_STR and DEFAULT_PGSOCKET_DIR, and the TAP test writes its
passfile entry under whatever port that reports, so no 5432 assumption
anywhere.  NULL and empty port are both covered.  I tried it against a
build configured with -Dpgport=3D5499 and it passes there too.

 >   * NULL dbname and username are tested, but their empty-string forms
 >     are not.

Added both.  Small deviation here: the test client maps an argument of
"=3D" to an empty string instead of taking a real empty argument.  No
TAP test in the tree passes an empty argv element today, and I did not
want to find out on the Windows CI whether one survives process
spawning there.

 >   * NULL passfile with PGPASSFILE is tested, but empty passfile and the
 >     fallback to the default password file location are not.

Added both: an empty passfile falling back to PGPASSFILE, and a NULL
passfile with no PGPASSFILE falling back to ~/.pgpass, by pointing
HOME at a temporary directory (skipped on Windows, where the default
location does not come from the environment).

 >   * The documented default-socket-directory-to-localhost rule is not
 >     currently tested.

Added, using the socket directory reported by --passfile-defaults
(skipped if the platform reports none).

 > Testing that trailing fields are silently ignored appears to preserve
 > an undocumented parser behaviour.  Since that behaviour is inherited
 > from passwordFromFile() rather than introduced by this API, I would
 > prefer to leave it out of this patch.

Agreed, I removed the test case and its passfile line.

 >   * test_passfile_lookup() checks argc < 7 and silently accepts extra
 >     arguments.  argc !=3D 7 would match the usage string more closely.

Changed.

 >   * The C comment describing hostname defaults does not mention the
 >     default socket directory rule that is described in the SGML docs.

Added.

 >   * The returned allocation contains a plaintext password.
 >     PQfreemem() does not erase it, whereas libpq explicitly clears
 >     passwords stored in PGconn before freeing them.  It would be useful
 >     for the documentation to mention that callers are responsible for
 >     securely clearing the result where appropriate.

Added a paragraph to the docs: the result is a cleartext password,
PQfreemem() does not erase it, and callers that do not want it
lingering in memory should overwrite it before freeing.

v2 also wraps the doc synopsis like the neighboring entries do, and
now spells out that PGPASSFILE is the only environment variable the
function looks at (PGHOST and PGPORT are not applied to the lookup
keys).

I'll move the CF entry back to Needs review.

Thank you,
BR,
Diego