Re: Re: What needs to be done?

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@xythos.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 ;-)
>
>
>