Re: Re: What needs to be done?
От | Bruce Momjian |
---|---|
Тема | Re: Re: What needs to be done? |
Дата | |
Msg-id | 200109061659.f86Gxcb03028@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Re: What needs to be done? (Barry Lind <barry@xythos.com>) |
Список | pgsql-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@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 ;-) > > > > > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
В списке pgsql-jdbc по дате отправления:
Следующее
От: "chris markiewicz"Дата:
Сообщение: Re: error - NOTICE: current transaction...MORE DETAIL...