Re: BLOBs etc
От | Thomas Hallgren |
---|---|
Тема | Re: BLOBs etc |
Дата | |
Msg-id | thhal-0t1S7AgEJci4pBBPzoSc3JI48szX/RQ@mailblocks.com обсуждение исходный текст |
Ответ на | Re: BLOBs etc (Oliver Jowett <oliver@opencloud.com>) |
Список | pgsql-jdbc |
Oliver Jowett wrote: > Thomas Hallgren wrote: > > The thread in question is a month old; here's an archive link for the > benefit of the list: > > http://archives.postgresql.org/pgsql-hackers/2004-11/msg01018.php > Yes, that's the thread, for some reason I wasn't able to read the archives last night. The posting I was referring to is this one: http://archives.postgresql.org/pgsql-hackers/2004-11/msg01106.php > The followups seemed to be along the lines of "use EXTERNAL storage and > improve bytea to support partial updates". Is your proposal a serious > candidate for merging? > I didn't receive any comments on that proposal so nobody seemed to be particularly interested. Should the question come up again at a convenient time, and if some more people would provide feedback and perhaps help out, then yes, I might consider to actually contribute what I propose. I did some more thinking about transaction semantics and auto-commit. The above link will not really solve what you're after I think? But I'm not sure that the auto-commit differences will pose a problem. Let's assume that you have a bytea in a table and that you want to store something in that table using a Blob or binary stream in the client. The way I see it, this can be done in one of two ways. 1. You prepare a statement, you do a setBinaryStream, and then an executeUpdate. This is only one single statement so the auto-commit setting shouldn't really make a difference. The server must be changed to accommodate that it receives stream data instead of a bytea, but that's basically it. 2. You do a select and use a getBlob() on the ResultSet. The JDBC driver that reads the result will conclude that the column is actually a bytea so it will treat it as such and wrap it in a special Blob implementation in the client. The Blob instance must contain a primary key, a column identifier, and the data. If auto-commit is true, then each change made to this Blob using setBytes or writes through a stream obtained using getOutputStream would be committed immediately. Not very efficient but it would work. Another possibility is of course to consider this illegal. Now assume that it is the other way around. The database contains a LOB and you want to change it using setBytes. Again, this is a single statement so the auto-commit shouldn't make a difference. The server must be able to take the bytea data it gets when it was expecting stream data and transform that into a LOB access. Do you see more issues with auto-commit? Regards, Thomas Hallgren
В списке pgsql-jdbc по дате отправления: