One of the cool new features in the recent Postgres Plus Advanced Server release is the EDB*Wrap functionality. This fills a need in the ISV community coming from both the PostgreSQL world as well as Oracle by allowing developers to obfuscate their stored procedure code. Interestingly, this marks the second feature along with Optimizer Hints part of Postgres Plus that is “officially” designated as features the PostgreSQL community does not want.

http://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Want

The open source dweeb in me agrees with the community’s philosophies that PostgreSQL’s optimizer should be made smarter and the obfuscation is not 100% effective, but both features fill a business need. For EDB*Wrap, the business need is to make it difficult for people to see the source code of a stored procedure when it is sent as a plain text file.

So while it is not 100% effective, when an ISV shipping their stored procedure code encounters a malicious user who has the ability to turn:

$__EDBwrapped__$
UTF8
d86XAumhB/6bQTdJStisuVDG2FE3+vUz2Bjq2neAax7iG8Vg2++x1stc0gN3pCDO1+jnOc7orT9X
4sepJrX8Vn2nEf58u+V6f5UWLj43i2hDCO9iPyEa08jA8CuTFq0dL+B0DK5ymSL2MIrRMOz/eGn0
XEaU9TgaraXbIJhlNtCf
$__EDBwrapped__$

Into:
CREATE FUNCTION foo() RETURNS integer AS $$
BEGIN
RETURN 1;
END;
$$ LANGUAGE plpgsql;

That same user can also decompile their main application and their whole application becomes “open source” to the bad guy. In the commercial world, it is hard to hold back features customers are requesting because of a corner case you can manage through other means.