Skip site navigation (1) Skip section navigation (2)

Re: Re: What needs to be done?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Barry Lind <barry(at)xythos(dot)com>
Cc: Gunnar Rønning <gunnar(at)polygnosis(dot)com>, Anders Bengtsson <ndrsbngtssn(at)yahoo(dot)se>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Re: What needs to be done?
Date: 2001-09-06 16:59:38
Message-ID: 200109061659.f86Gxcb03028@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-jdbc
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 <barry(at)xythos(dot)com> 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                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-hackers by date

Next:From: Vince VielhaberDate: 2001-09-06 17:01:08
Subject: Re: Re: What needs to be done?
Previous:From: Bruce MomjianDate: 2001-09-06 16:54:59
Subject: Re: Re: What needs to be done?

pgsql-jdbc by date

Next:From: Vince VielhaberDate: 2001-09-06 17:01:08
Subject: Re: Re: What needs to be done?
Previous:From: Bruce MomjianDate: 2001-09-06 16:54:59
Subject: Re: Re: What needs to be done?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group