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.
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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
