Re: BLOB support
От | Radosław Smogura |
---|---|
Тема | Re: BLOB support |
Дата | |
Msg-id | 201106022126.29313.rsmogura@softperience.eu обсуждение исходный текст |
Ответ на | Re: BLOB support (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BLOB support
|
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> Thursday 02 of June 2011 19:43:16 > Radosław Smogura <rsmogura@softperience.eu> writes: > > Tom Lane <tgl@sss.pgh.pa.us> Thursday 02 of June 2011 16:42:42 > > > >> 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.) > > > > In context of LOBs streaming is resolved... I use current LO > > functionallity (so driver may be able to read LOBs as psql \lo_export > > does it or using COPY subprotocol) and client should get just LO's id. > > Just to be clear: I do not want to expose a concept of object IDs for > field values in the first place. All of the problems you enumerate stem > from the idea that LOBs ought to be a distinct kind of field, and I > don't buy that. > > regards, tom lane So do I understand good should We think about create bettered TOAST to support larger values then 30-bit length? I like this much more, but without Objects ID quering relation with lobs will require to lock relation for some time, as client will need to reference LOB in some way, I think using TID or some derivative of TID, am I right? Regards, Radek
В списке pgsql-hackers по дате отправления: