Re: Re: What needs to be done?

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