Tom Lane <t...@sss.pgh.pa.us> Friday 03 of June 2011 18:08:56 > Robert Haas <robertmh...@gmail.com> writes: > > On Thu, Jun 2, 2011 at 12:53 PM, RadosÅaw Smogura > > > > <rsmog...@softperience.eu> wrote: > >> 1. No tracking of unused LO (you store just id of such object). You may > >> leak LO after row remove/update. User may write triggers for this, but > >> it is not argument - BLOB type is popular, and it's simplicity of use > >> is quite important. When I create app this is worst thing. > >> > >> 2. No support for casting in UPDATE/INSERT. So there is no way to simple > >> migrate data (e.g. from too long varchars). Or to copy BLOBs. > >> > >> 3. Limitation of field size to 1GB. > > > > As a general point, it would probably be a good idea to address each > > of these issues separately, and to have a separate discussion about > > each one. > > > > As to #1 specifically, if you use a text or bytea field rather than a > > large object per se, then this issue goes away. But then you lose the > > streaming functionality. So at least some people here are saying that > > we should try to fix that by adding the streaming functionality to > > text/bytea rather than by doing anything to the large object facility. > > #2 is also a problem that only becomes a problem if you insist that LOBs > have to be a distinct kind of value. > > regards, tom lane
And one more topic to discuss. Should blob be referencable, e.g. I create in JDBC new Blob, I set stream for it what should happen if I will call UPDATE t set b = ? where 1=1 ? This is not about copy on write. Regards, Radek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
