I wrote:
> Poking around, it looks like parseServiceInfo's search for
> ~/.pg_service.conf has the same disease, but that code's been like that
> since 2010 --- I wonder why it's not causing you problems? Are you maybe
> setting PGSERVICEFILE to prevent that from failing?
Ah, looking closer, we don't reach that code unless you've specified a
service name (either as a connection parameter or through the PGSERVICE
environment variable). So it's not so surprising that nobody complained
about that case yet. But it's still wrong.
regards, tom lane