> 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? ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster