1
0
mirror of https://github.com/postgres/postgres.git synced 2025-06-17 17:02:08 +03:00

Attached is a patch to add bytea support to JDBC.

This patch does the following:

- Adds binary datatype support (bytea)
- Changes getXXXStream()/setXXXStream() methods to be spec compliant
- Adds ability to revert to old behavior

Details:

Adds support for the binary type bytea.  The ResultSet.getBytes() and
PreparedStatement.setBytes() methods now work against columns of bytea
type.  This is a change in behavior from the previous code which assumed
the column type was OID and thus a LargeObject.  The new behavior is
more complient with the JDBC spec as BLOB/CLOB are to be used for
LargeObjects and the getBytes()/setBytes() methods are for the databases
binary datatype (which is bytea in postgres).

Changes the behavior of the getBinaryStream(), getAsciiStream(),
getCharacterStream(), getUnicodeStream() and their setXXXStream()
counterparts.  These methos now work against either the bytea type
(BinaryStream) or the text types (AsciiStream, CharacterStream,
UnicodeStream).  The previous behavior was that these all assumed the
underlying column was of type OID and thus a LargeObject.  The
spec/javadoc for these methods indicate that they are for LONGVARCHAR
and LONGVARBINARY datatypes, which are distinct from the BLOB/CLOB
datatypes.  Given that the bytea and text types support upto 1G, they
are the LONGVARBINARY and LONGVARCHAR datatypes in postgres.

Added support for turning off the above new functionality.  Given that
the changes above are not backwardly compatible (however they are more
spec complient), I added the ability to revert back to the old behavior.
  The Connection now takes an optional parameter named 'compatible'.  If
the value of '7.1' is passed, the driver reverts to the 7.1 behavior.
If the parameter is not passed or the value '7.2' is passed the behavior
is the new behavior.  The mechanism put in place can be used in the
future when/if similar needs arise to change behavior.  This is
patterned after how Oracle does this (i.e. Oracle has a 'compatible'
parameter that behaves in a similar manner).

Misc fixes.  Cleaned up a few things I encountered along the way.


Note that in testing the patch I needed to ignore whitespace differences
in order to get it to apply cleanly (i.e. patch -l -i byteapatch.diff).
Also this patch introduces a new file
(src/interfaces/jdbc/org/postgresql/util/PGbytea.java).

Barry Lind
This commit is contained in:
Bruce Momjian
2001-09-10 15:07:05 +00:00
parent 6b50f9af33
commit ec0ad67403
10 changed files with 557 additions and 49 deletions

View File

@ -11,7 +11,7 @@ import org.postgresql.util.*;
import org.postgresql.core.*;
/**
* $Id: Connection.java,v 1.28 2001/09/07 22:17:02 momjian Exp $
* $Id: Connection.java,v 1.29 2001/09/10 15:07:05 momjian Exp $
*
* This abstract class is used by org.postgresql.Driver to open either the JDBC1 or
* JDBC2 versions of the Connection class.
@ -22,15 +22,13 @@ public abstract class Connection
// This is the network stream associated with this connection
public PG_Stream pg_stream;
// This is set by org.postgresql.Statement.setMaxRows()
//public int maxrows = 0; // maximum no. of rows; 0 = unlimited
private String PG_HOST;
private int PG_PORT;
private String PG_USER;
private String PG_PASSWORD;
private String PG_DATABASE;
private boolean PG_STATUS;
private String compatible;
/**
* The encoding to use for this connection.
@ -123,6 +121,11 @@ public abstract class Connection
PG_PORT = port;
PG_HOST = host;
PG_STATUS = CONNECTION_BAD;
if(info.getProperty("compatible")==null) {
compatible = d.getMajorVersion() + "." + d.getMinorVersion();
} else {
compatible = info.getProperty("compatible");
}
// Now make the initial connection
try
@ -968,6 +971,23 @@ public abstract class Connection
return (getDBVersionNumber().compareTo(ver) >= 0);
}
/**
* This method returns true if the compatible level set in the connection
* (which can be passed into the connection or specified in the URL)
* is at least the value passed to this method. This is used to toggle
* between different functionality as it changes across different releases
* of the jdbc driver code. The values here are versions of the jdbc client
* and not server versions. For example in 7.1 get/setBytes worked on
* LargeObject values, in 7.2 these methods were changed to work on bytea
* values. This change in functionality could be disabled by setting the
* "compatible" level to be 7.1, in which case the driver will revert to
* the 7.1 functionality.
*/
public boolean haveMinimumCompatibleVersion(String ver) throws SQLException
{
return (compatible.compareTo(ver) >= 0);
}
/**
* This returns the java.sql.Types type for a PG type oid