Robert Haas <robertmh...@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.
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
