> Martijn van Oosterhout <kleptog@svana.org> writes:
>> I think the major issue is that most such systems (like RFC2782) deal
>> only with finding the hostname:port of the service and don't deal with
>> usernames/passwords/dbname. What we want is a system that not only
>> finds the service, but tells you enough to connect.
>
> In other words, anyone on the LAN who asks nicely can get a database
> password? No thank you.
>
> I don't actually believe that a server-side substitute for pg_service
> would be worth anything at all. First, it just begs the question of
> how you find the server. Second, pg_service is only really interesting
> if there are multiple servers you want to connect to. It's not
> reasonable to assume that one of them will know about any (let alone
> all) of the others. Once you start to think about security it's even
> worse: you've got that one storing passwords and so on for the other
> servers.
Tom, mark your calendar, I think in this one instance, we are in 100%
total agreement. I'm not sure what this means, does one of have to change
our opinion?
Actually, pg_service.conf, as I think more about it, is more than just
"pg_service is only really interesting if there are multiple servers you
want to connect to," it even abstracts the physical database name, which
is interesting as well.
>
> My complaint about pg_service is actually that it should have been
> designed to support per-user values more easily. It's a takeoff on
> the ODBC ini file concept, but we forgot the per-user ~/.odbc.ini part.
I can certainly see that application, and it should be trivial to add any
that code. Do you think it is worth doing?