Bill Moran wrote: > Not to start an argument, but you could reverse that logic and say "Do you want > to hurt the smart, ssl users by not including helpful functionality that could > be dangerous to uneducated non-ssl users?" > > IMHO, it really depends on the design philosophy that PostgreSQL follows. I'm > familiar with the strong push for stability, and I approve. But I'm not as > sure I have a feel for what developers think about this kind of thing. > > If you made it a compile-time option, or made it disabled by default and > requires a special setting in postgresql.conf to enable. Would that be secure? > Not really, as stupid users would still enable it without understanding, and > there's always the possibility that a some packager would build it with > dangerous settings and distribute it widely. > > (As a side note, I seem to remember a program that had a --shoot-my-own-foot > option to ./configure ... but I can't remember what it was ...) > > So, the question becomes one of design philosophy (at least, I'm basing this on > the concept that actual implementation would not be too hard, correct me if I'm > wrong)
You are correct. The question is whether it is worth adding that level of complexity into the system --- in the past, we have decided it isn't. We have the $HOME/.pgpass file to store username/password combinations that is probably best, though it works only with libpq-based interfaces. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
