While I don’t think this is some sort of coordinated plan by Larry to bring down open source in general, I think this is indicative of the pain of integrating Sun in to Oracle and we can expect more of this in the future. On the positive side, I think the reactions by the PostgreSQL and Eclipse communities really highlight the power of the open source process. In both cases, the communities had solutions quickly in the wake of the mess created by Oracle.

object MainDBC {

  import scala.dbc._
  import scala.dbc.Syntax._
  import syntax.Statement._

  def main(args: Array[String]): Unit = {
    val db = database("jdbc:postgresql://localhost/scala","postgres","password")
    val res = db.executeStatement {
      (select fields (("pgbench_tellers.tid" of integer)
                  and ("pgbench_tellers.bid" of integer)
                  and ("pgbench_branches.bbalance" of integer))
         from "pgbench_tellers, pgbench_branches"
        where "pgbench_tellers.bid = pgbench_branches.bid")
    }

    println(" tid   bid   bbalance")
    println("----- ----- ----------")
    for(val i <- res) {
      for(val f <- i.fields) {
        val r = f.content.sqlString
        print(r + "      ".dropRight(r.length))
      }
      println()
    }
  }
}

There are a number of object layers available that may be much easier to use, but the nice thing about Scala running on the JVM is that you can leverage the low level JDBC interface and eliminate much of the awkwardness. Below is an example of the same query but using JDBC.

object MainJDBC {

  import java.sql.{Connection, DriverManager, ResultSet}

  def main(args: Array[String]): Unit = {
    classOf[org.postgresql.Driver]
    val db = DriverManager.getConnection("jdbc:postgresql://localhost/scala","postgres","password")
    val st = db.createStatement

    val res = st.executeQuery(
               "SELECT pgbench_tellers.tid, pgbench_tellers.bid, pgbench_branches.bbalance" +
               "  FROM pgbench_tellers, pgbench_branches " +
               " WHERE pgbench_tellers.bid = pgbench_branches.bid")

    println(" tid   bid   bbalance")
    println("----- ----- ----------")
    while (res.next) {
        for(val i <- 1 to res.getMetaData.getColumnCount) {
          val r = res.getInt(i).toString
          print(r + "      ".dropRight(r.length))
        }
        println
    }
    db.close
  }
}

The other interesting trend was the types of applications organizations are considering for use in the cloud. While there is much talk about replatforming existing application onto Cloud Computing infrastructures, many organizations seem to people getting their feet wet with new applications. They seem to be fairly traditional applications and not leveraging the elasticity of the cloud and they are just leveraging the financial benefits of not needed to procure new hardware. This trend show a lot of great promise for PostgreSQL given that Oracle does not have a favorable licensing model in virtualized environments. While Oracle is expensive in traditional environments, much of the cost benefits are eroded when Oracle is needed in a cloud environment. This is leading many people to open source solutions and PostgreSQL is a natural fit for many Oracle users.

These attacks will lead to more technological innovation in the ever growing security arms race. Just yesterday, GreenSQL released a new version of their database firewall that supports PostgreSQL. While database firewall technology is an effective tool in preventing SQL Injection attacks, it may not be a viable option in many situations. Many application rely heavily on the performance and scalability of the database engine and adding a layer of complex processing between the application and database has its drawbacks. The innovation still needs to progress before SQL Injection attacks become a lot less common place in the wild world of the internet.

Without an integrated solution that will monitor the different pieces infrastructure, tracking down potential bottlenecks becomes a nightmare. Hyperic can be overkill in some small environments, but its model is something the PostgreSQL community should consider instead of writing yet another monitoring tool.