2011/6/2 Pavel Golub <pa...@microolap.com>: > Hello, Pavel. > > You wrote: > > PS> 2011/6/2 Peter Eisentraut <pete...@gmx.net>: >>> On ons, 2011-06-01 at 22:00 +0200, Radosław Smogura wrote: >>>> I partialy implemented following missing LOBs types. Requirement for this >>>> was >>>> to give ability to create (B/C)LOB columns and add casting functionality >>>> e.g. >>>> SET my_clob = 'My long text'. >>>> >>>> Idea is as follow: >>>> 0. Blob is two state object: 1st in memory contains just bytea, serialized >>>> contains Oid of large object. >>>> 1. Each type has additional boolean haslobs, which is set recursivly. >>>> 2. Relation has same bool haslobs (used to speed up tables without LOBs) >>>> 3. When data are inserted/updated then "special" function is called and >>>> tuple >>>> is modified in this way all LOBs are serialized to (old) LOB table and just >>>> Oid is stored. >>>> 4. When removed LOB is removed from (old) LOB table. >>> >>> Superficially, this looks like a reimplementation of TOAST. What >>> functionality exactly do you envision that the BLOB and CLOB types would >>> need to have that would warrant treating them different from, say, bytea >>> and text? >>> > > PS> a streaming for bytea could be nice. A very large bytea are limited by > PS> query size - processing long query needs too RAM, > > LO (oid) solves this, doesn't it?
partially There is a few disadvantages LO against bytea, so there are requests for "smarter" API for bytea. Significant problem is different implementation of LO for people who have to port application to PostgreSQL from Oracle, DB2. There are some JDBC issues too. For me - main disadvantage of LO in one space for all. Bytea removes this disadvantage, but it is slower for lengths > 20 MB. It could be really very practical have a possibility insert some large fields in second NON SQL stream. Same situation is when large bytea is read. Pavel > > PS> Pavel > >>> >>> >>> -- >>> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) >>> To make changes to your subscription: >>> http://www.postgresql.org/mailpref/pgsql-hackers >>> > > > > > -- > With best wishes, > Pavel mailto:pa...@gf.microolap.com > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
