2011/6/2 Tom Lane <tgl@sss.pgh.pa.us>:
> Robert Haas <robertmhaas@gmail.com> writes:
>> 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.
>
> Yes. I think the appropriate problem statement is "provide streaming
> access to large field values, as an alternative to just fetching/storing
> the entire value at once". I see no good reason to import the entire
> messy notion of LOBS/CLOBS. (The fact that other databases have done it
> is not a good reason.)
>
> For primitive types like text or bytea it seems pretty obvious what
> "streaming access" should entail, but it might be interesting to
> consider what it should mean for structured types. For instance, if I
> have an array field with umpteen zillion elements, it might be nice to
> fetch them one at a time using the streaming access mechanism. I don't
> say that that has to be in the first version, but it'd be a good idea to
> keep that in the back of your head so you don't design a dead-end
> solution that can't be extended in that direction.
+1
Pavel
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
