Added to TODO:

* -Make binary interface for TOAST columns (base64)
* Make file in/out interface for TOAST columns, similar to large object
  interface (force out-of-line storage and no compression)              

> This is what I think needs to be done wrt large objects and binary data 
> support (and hopefully what I plan to do sometime before 7.2 beta, but 
> if anyone else feels up to it, feel free to do any of these things 
> yourself):
> Add support for the postgresql binary datatype 'bytea'.  This means 
> adding the logic to encode/decode binary data into the ascii escape 
> sequences used by postgresql.  This also means that the 
> getBytes()/setBytes() methods will be changed to interact with the bytea 
> datatype instead of the current mapping to large objects.  This is a non 
> backwardly compatable change in functionality that makes the driver more 
> compliant with the spec.
> Second I plan to change the getBinaryStream()/setBinaryStream() methods 
> to likewise work on the bytea datatype instead of large objects.  Given 
> that toast allows bytea values to be upto 1G in size a stream interface 
> makes sense.  This change also breaks backward compatibilty, but is more 
> spec compliant.  The spec implies that these methods are for accessing 
> regular binary data (i.e. bytea), and that the 
> getBlob().getBinaryStream() is for binary large object access.
> Third, I plan to change the getCharacterStream()/setCharacterStream() 
> methods to work against text datatypes (text, char, varchar) instead of 
> large objects.  Same reason and same consequences as for the binary 
> stream methods.
> That will leave getBlob()/setBlob() and getClob()/setClob() as the 
> supported way of accessing large objects (along with the LargeObject 
> class itself).  Which my reading of the spec says is correct.
> Now in the long run, I would even like to change 
> getBlob()/setBlob()/getClob()/setClob() methods to no longer support the 
> old large object functionality of postgresql but to move these to 
> support a 'toast' version of large objects (once the corresponding 
> access methods to toasted columns exist so that toasted columns can 
> really be treated as large objects).  This would solve the problem with 
> deletes not deleting the large objects.  At that time the only way to 
> access the old large object functionality would be through the 
> functionality provided by the LargeObject class.
> As you can probably guess I don't like the current implementation of 
> large objects in postgresql (and I haven't even gotten into the security 
> issues they have).  I believe that 'toast' will provide the 
> functionality of large objects in the future in a way that is compatable 
> with other databases and the JDBC Blob/Clob interface.  Until the time 
> that toast is ready, I believe we need to make the above changes and 
> document very clearly the issues with the current large object 
> functionality.
> thanks,
> --Barry
> Gunnar R?nning wrote:
> > [Answering as Anders Norwegian brother :-]
> >  
> > * Barry Lind <[EMAIL PROTECTED]> wrote:
> > |
> > | Anders,
> > | 
> > | What aspects of BLOB support do you consider broken?  Are these
> > | aspects that are broken in the JDBC layer or are 'broken' at the
> > | server layer?
> > 
> > We should have support for the bytea datatype, so applications are not
> > required to wrap blob operations into a transaction. This has been 
> > a showstopper for using PostgreSQL with the Turbine framework at Apache
> > for a long time. If we get that to work with PostgreSQL we will attract
> > more users and be a step closer to world domination ;-)
> > 
> > 
> > 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

  Bruce Momjian                        |
  [EMAIL PROTECTED]               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to