> > On Mon, Sep 15, 2008 at 11:35:30AM -0400, Jonathan Bond-Caron wrote: > > Harald wrote: > > > > > > If you are, > > > > it's an argument for security by obscurity, a system with a lot of > > > > deep known flaws. > > > > > That would be more the "Oracle stored procedures can be encrypted." > > > Which is an argument for ISVs, as they can easier force their > > > customers to pay "software maintainance". > > > > > With open code, clients could buy support from others, who may be > > > cheaper or, even more dangerous, more qualified. > > > > > As long as the disease of "Intellectual property" is running around, > > > that "I can encrypt my code" will provide some felt benefit for > > > PHBs.... > > > > I have to disagree here. Encrypting stored procedures is not just > > about forcing customers to pay software maintenance. > > Please to explain how you imagine this to be so. > It could be intra-company as well. For instance, a Finance group doing forecasting in PG wants to prevent others from looking calculations. Or an M&A group models different scenarios and doesn't want to share this code ever with people outside of their group. Asking them to write C is too much. There are lots of scenarios where a group wants to protect their PL/PGSQL code from others but wants to grant users access to the database. The current openness of PG code (code written by users, not the source code of PG), is not ideal for these scenarios. In Oracle, you must be granted the ability to see someone's PL/SQL code. Secondly, you can "wrap" the code so no one can read it which protects the intellectual property aspect. I'm far less interested in protecting intellectual property because I'm not in that business. I am much more interested in meeting business needs which means securing not only the data in the database but also the code users write. Jon
