On Thu, Jun 2, 2011 at 9:29 AM, Radosław Smogura
<rsmogura@softperience.eu> wrote:
>> 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?
>
> Actually I thought about less sophisticated support of LOBs, supporting
> casting and copying data, as well known form other databases idea that LOBs
> are not "downloaded" during normal query execution (just ids are taken).
> Currently, e.g. LOBs are not connected with tables, so deleting rows doesn't
> delete LOB, table actually holds Oid of large objects, no support for
> casting to/from LOB, no support for CLOBS. Some drivers try to emulate
> BLOBs/CLOBs, but it is not perfect, mainly from above reasons.
But these problems can be fixed without inventing a completely new
system, I think. Or at least we should try. I can see the point of a
data type that is really a pointer to a LOB, and the LOB gets deleted
when the pointer is removed, but I don't think that should require
far-reaching changes all over the system (like relhaslobs) to make it
work efficiently. I think you need to start with a problem statement,
get agreement that it is a problem and on what the solution should be,
and then go write the code to implement that solution. This is a
classic example of writing the code first and then working backwards
toward the problem you're trying to solve, and that rarely works out
well for the reasons that you're now finding out: people may not agree
with your proposed solution, they may want things done differently,
and now you're stuck reworking code that you've already written. It's
much easier to change a design document than it is to rewrite code.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company