>
> 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