Re: Feature idea

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
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073