2011/6/2 Tom Lane <t...@sss.pgh.pa.us>: > 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.
+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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
