mirror of
https://github.com/postgres/postgres.git
synced 2025-08-30 06:01:21 +03:00
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 is a simple readme describing how to compile and use the jdbc driver. This file was amended on January 17 2001 to reflect the changes made in the 7.1 release. --------------------------------------------------------------------------- This isn't a guide on how to use JDBC - for that refer to Javasoft's web site: http://www.javasoft.com/ For problems with this driver, then refer to the postgres-jdbc email list: http://www.postgresql.org/ The Driver's home page is: http://jdbc.postgresql.org/ or http://www.retep.org.uk/postgresql/ NB: They are both the same physical directory so both will always be in sync (unless the laws of physics break down ;-) ) --------------------------------------------------------------------------- COMPILING To compile you will need to have ANT installed. To obtain ant go to http://jakarta.apache.org/ant/index.html and download the binary. Being pure java it will run on virtually all java platforms. If you have any problems please email the jdbc list. Once you have ANT, run the configure script in the top-level directory with the --with-java option. Then proceed with 'make' and 'make install' as usual. This will compile the correct driver for your JVM, and build a .jar file (Java ARchive) called postgresql.jar. The file will be installed in the directory PREFIX/share/java. That jar file will contain the driver for _your_ version of the JDK. Note: As of 7.1, you can build from the top-level directory or from src/interfaces/jdbc. REMEMBER: Once you have compiled the driver, it will work on ALL platforms that support that version of the API. You don't need to build it for each platform. That means you don't have to compile it on every platform. Believe me, I still hear from people who ask me "I've compiled it ok under Solaris, but it won't compile under Linux" - there's no difference. Don't try to run javac directly. Don't try to run ant directly. Neither will work. Possible problems You may see a message similar to: postgresql/Driver.java:87: interface java.sql.Connection is an interface. It can't be instantiated. return new Connection (host(), port(), props, database(), url, this); This is caused by not having the current directory in your CLASSPATH. Under Linux/Solaris, unset the CLASSPATH environment variable, and rerun ant. If you are still having problems, I keep a copy of the driver (for different versions of the backend) on my web site http://www.retep.org.uk/postgres/ or http://jdbc.postgresql.org/ More details are in the Implementation file src/interfaces/jdbc/Implementation --------------------------------------------------------------------------- INSTALLING THE DRIVER To install the driver, the .class files have to be in the classpath. ie: under LINUX/SOLARIS (the example here is my linux box): export CLASSPATH=.:/usr/local/pgsql/share/java/postgresql.jar Please don't be tempted to extract the files from the .jar file. There are a lot of files in there, and you may break the Exception handling. --------------------------------------------------------------------------- USING THE DRIVER To use the driver, you must introduce it to JDBC. Again, there's two ways of doing this: 1: Hardcoded. This method hardcodes your driver into your application/applet. You introduce the driver using the following snippet of code: try { Class.forName("org.postgresql.Driver"); } catch(Exception e) { // your error handling code goes here } Remember, this method restricts your code to just the postgresql database. However, this is how most people load the driver. 2: Parameters This method specifies the driver from the command line. When running the application, you specify the driver using the option: -Djdbc.drivers=org.postgresql.Driver eg: This is an example of running one of my other projects with the driver: java -Djdbc.drivers=org.postgresql.Driver uk.org.retep.finder.Main note: This method only works with Applications (not for Applets). However, the application is not tied to one driver, so if you needed to switch databases (why I don't know ;-) ), you don't need to recompile the application (as long as you havent hardcoded the url's). --------------------------------------------------------------------------- JDBC URL syntax The driver recognises JDBC URL's of the form: jdbc:postgresql:database jdbc:postgresql://host/database jdbc:postgresql://host:port/database Also, you can supply both username and passwords as arguments, by appending them to the URL. eg: jdbc:postgresql:database?user=me jdbc:postgresql:database?user=me&password=mypass Notes: 1) If you are connecting to localhost or 127.0.0.1 you can leave it out of the URL. ie: jdbc:postgresql://localhost/mydb can be replaced with jdbc:postgresql:mydb 2) The port defaults to 5432 if it's left out. --------------------------------------------------------------------------- That's the basics related to this driver. You'll need to read the JDBC Docs on how to use it. However, there are some examples included in the example directory. To build, type: make examples To run them, they follow the same syntax. For example, the basic example shows how to insert data, and perform queries: java example.basic jdbc:postgresql:test user password --------------------------------------------------------------------------- POSTGRESQL SPECIFICS -------------------- Large Objects: A "feature" of PostgreSQL is that access to LargeObjects is only permitted within a Transaction. Because of this, any use of LargeObjects (also known as Blobs) requires that the Connection.setAutoCommit() method be called disabling the autocommit feature. For example: Connection db; // open the connection here db.setAutoCommit(false); // Turn off AutoCommit ------------------ Large Object API Most of the time, you can use the getBytes()/setBytes() methods to read and write small Large Objects. However, PostgreSQL's own internal api's are available. These allow you to access the object as if it was a file. The first thing you need to do is to open the LargeObjectManager. This class handles the opening of existing objects, and creating new ones. To do this, you use the following line of code: LargeObjectManager lobj; lobj = ((org.postgresql.Connection)db).getLargeObjectAPI(); where db is a reference to an open Connection object. Once that is done, you can use the API for the lifetime of that Connection. To create an object, you call the create() method. This takes an argument with the file modes you intend to use. The following line is normally sufficient: int oid = lobj.create(LargeObjectManager.READ|LargeObjectManager.WRITE); Here, lobj is the LargeObjectManager we have opened earlier, and oid is the Large Object's oid in the database. To open an existing object, you use the open() method. This takes an oid, and the file permissions. It then returns a LargeObject object. LargeObject obj = lobj.open(oid,LargeObjectManager.WRITE); Once the LargeObject is open, you can call methods to read, write, seek etc. Here's the supported methods: int oid = obj.getOID(); Return the objects oid obj.close(); Close the object byte data[] = obj.read(int len); Read len bytes onj.read(byte data[],int off,int len); Read into data[off] len bytes obj.write(byte data[]); Write the array data obj.write(byte data[],int off,int len); Write len bytes from data[off] obj.seek(int pos,int ref); As fseek in C. obj.seek(int pos); Move to pos (from the begining) int pos = obj.tell(); Returns the current position int size = obj.size(); Returns the objects size Caveat: If you commit(), rollback() a transaction, or turn on autocommit whilst an object is open PostgreSQL will close it. You will need to reopen the object before using it again. Using the existing LargeObject will cause an SQLException to be thrown. ------------------ Date datatype: The driver now issues the "show datestyle;" query when it first connects, so any call to ResultSet.getDate() how returns the correct date. One caveat though: if you change the datestyle from within JDBC, you must also issue the "show datestyle" query. Without this, the driver will not know of the change. ie: Statement s = db.createStatement(); ... s.executeUpdate("set datestyle='european'"); s.executeUpdate("show datestyle"); .. s.close(); Please note: This may change later, so that the driver uses the same format internally (similar to how the ODBC driver works). ------------------ JDBC supports database specific data types using the getObject() call. The following types have their own Java equivalents supplied by the driver: box, circle, line, lseg, path, point, polygon When using the getObject() method on a resultset, it returns a PG_Object, which holds the postgres type, and its value. This object also supports methods to retrive these types. Eg: column 3 contains a point, and rs is the ResultSet: PG_Object o = (PG_Object)rs.getObject(3); PGpoint p = o.getPoint(); System.out.println("point returned x="+p.x+", y="+p.y); Also, when using these classes, their toString() methods return the correct syntax for writing these to the database. --------------------------------------------------------------------------- Peter T Mount, December 29 1998 home email: peter@retep.org.uk http://www.retep.org.uk work email: petermount@it.maidstone.gov.uk or peter@taer.maidstone.gov.uk PS: Please use the home email whenever possible. If you must contact me at work then please cc my home one at the same time.