Last week, the PostgreSQL community announced the general availability of PostgreSQL 8.4. This is another great release from the community with a number of great new features such as analytical functions and even deeper security. All worthy features to be highlighted as the headline of the release, but the true headline feature is not even part of the core engine. In conjunction with the 8.4 release, Bruce Momjian is in the process of releasing pg_migrator as an external project that allows users to upgrade their database in place. While most databases has had this functionality for years, it is something that PostgreSQL has lacked and in my opinion has held PostgreSQL back from deeper enterprise adoption. Previously, to move to a new major release, users would need to export their data from the old version and then import it into the new version. This works well when the database is small, but if the database is large, it could mean hours or days of downtime to upgrade the database along with at least double the storage to hold the two copies. This is completely unacceptable to enterprises that need to maintain a 24×7 environment. I believe that pg_migrator has cleared on the the few major technical hurdles preventing PostgreSQL from widespread commercial adoption.
PostgreSQL 8.4 ReleasedAuthor Archive
Features We Do Want
Monday, June 29th, 2009 by Jim MlodgenskiOne 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.
Features We Do Want
