Re: Prepared Statements - Mailing list pgsql-jdbc

(Cc: list trimmed)

On Sun, Jul 20, 2003 at 10:36:53PM -0400, Dima Tkach wrote:

> Yep. That's exactly why I was arguing against having it to beging with
> back in the beginning of 7.3
> .. I lost that one too :-(
> ... but still believe it was the wrong idea.
> I mean, as I said before, I do have do go an extra mile because of this
> precompiled query plan stuff...
> I am  writing functions in C that cache query plans and return strings,
> and call them from java, and pase strings back in rows...  I just can't
> afford casting my statements to org.jdbc.postgres.Something... sorry - I
> can't write my apps assuming that postgres is the only db they'll ever
> need :-(

Um, so you don't want to depend on the JDBC postgresql driver at all, but
don't mind having postgresql-specific behaviour elsewhere so long
as you can do it purely through the JDBC interface? That seems a bit
inconsistent.

Note that using setObject() to set IN clauses is no less postgresql-specific
than using setArray() would be .. I know of at least one DB where you really
can only set data values in a prepared statement as the prepared SQL is
compiled down to a form of bytecode for DB-side execution, there *is* no
textual substitution that goes on.

What I was suggesting was a scheme like:

  interface JDBCExtensions {
     void initStatement(PreparedStatement stmt);
     void setInClause(PreparedStatement stmt, int index, int[] values);
  }

  class PostgresqlJDBCExceptions implements JDBCExtensions {
    public void initStatement(PreparedStatement stmt) {
      ((org.postgresql.PGStatement)stmt).setUseServerPrepare(true);
    }

    public void setInClause(PreparedStatement stmt, int index, int[] values) {
      stmt.setArray(index, new org.postgresql.jdbc2.WrappedArray(values, Types.INTEGER));
    }
  }

  class FooJDBCExceptions implements JDBCExtensions {
    // implementation for FooDB
  }

  // ...

  Class datasourceClass = Class.forName(configuredDatasourceClass);
  Class extensionsClass = Class.forName(configuredExtensionsClass);
  JDBCExtensions extensions = extensionsClass.newInstance();

  // ...

  PreparedStatement stmt = connection.prepareStatement(...);
  extensions.initStatement(stmt);
  extensions.setInClause(stmt, 4, new int[] { 1,2,3,4 });

Then conditionalize compilation of implementations of JDBCExceptions on the
presence of the appropriate driver. When built, you get extension support
for all the drivers present on the build system. When running from a built
jar, only the configured extension class is loaded (and presumably the
end-user has the corresponding JDBC driver available, or they can't talk to
the DB anyway!)

What prevents you from taking this approach?

-O