Hi,
While testing “psql: Add variable SERVICEFILE”, I found a small issue where SERVICEFILE may show the wrong value.
While tracing the code, I noticed there is a fallback path. If the service file specified in the connection string does
notcontain the requested service, libpq falls back to pg_service.conf. So I tested the following case:
1. Prepare two service files: one empty, and the other containing the service:
```
% mkdir -p /tmp/svc
% : > /tmp/svc/empty.conf
% printf '[actual]\n' > /tmp/svc/pg_service.conf
```
2. Run psql with a connection string and show SERVICEFILE:
```
% PGSYSCONFDIR=/tmp/svc psql "dbname=postgres service=actual servicefile=/tmp/svc/empty.conf"
psql (19beta1)
Type "help" for help.
postgres=# \echo :SERVICE :SERVICEFILE
actual /tmp/svc/empty.conf
```
Here, SERVICEFILE shows the empty file /tmp/svc/empty.conf, which is wrong because the actual service is read from
/tmp/svc/pg_service.conf.
I think the bug was actually introduced by the previous commit 092f3c63efc6. In parseServiceFile(), if the service file
hasalready been set in the connection options, it refuses to update the value, so the fallback service file is not
syncedto the connection options. Then SERVICEFILE is read from the connection options, which still contain the original
filespecified on the command line. So, SERVICEFILE just makes the bug visible.
The fix is simple, when fallback happens, explicitly store the actual service file into the connection options. See the
attachedpatch for details.
With the fix, SERVICEFILE shows the actual service file:
```
% PGSYSCONFDIR=/tmp/svc psql "dbname=postgres service=actual servicefile=/tmp/svc/empty.conf"
psql (19beta1)
Type "help" for help.
postgres=# \echo :SERVICE :SERVICEFILE
actual /tmp/svc/pg_service.conf
```
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
