On Tue, 20 Aug 2002 15:22, Neil Conway wrote: > I'd say the two issues are pretty different. IMHO, buffer overruns and > similar security problems are just a special class of software bug > (it's interesting to note that most of the buffer overruns have been > found in the less-maintained parts of the system, like the cash type > or contrib/). Therefore, the justification for fixing buffer overruns > (and avoiding them in the first place) is the same as for fixing other > kinds of bugs: it makes the system more reliable.
Agreed - different issues, similar argument. They should be fixed, I just don't think its a sky is falling type problem. Not saying you said I was (*grin*), just that a competent network administrator has taken steps to secure the database over and above that expected of the developers. > It's probably worth noting that the "barrier to entry" for fixing > buffer overruns or doing a code audit is much, much lower than for > implementing advanced features like schemas or replication. The main > thing that auditing code requires is time, rather than coding > skill/knowledge. Definitely, and I wish I had some to spend on Postgres! Time that is :) As you noted, most of the issues are in contrib - obviously due to the skills/knowledge of the core team and the strength of the development model. However, if the quality of programmers in the market is anything to go by, I don't hold out for the future unless Postgres is rewritten in something that holds hands as well as Java :) Cheers Mark ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
