Jim Starkey wrote:
My thinking about blobs has changed. Blobs originally were an escape
from fixed length SQL types. Now that I've abandoned fixed length SQL
types, the utility of blob as a declared type diminishes to about
nothing. Nimbus will retain clob/blob types to humor the traditional,
but they will (probably) be synonyms for string and bytes,
respectively. There will still be a storage type for blobs, but it will
be dynamic, based on a length threshold. (Why, I can hear you asking?
Simple: There is no point to slop around a high-res jpeg to update a
last_reference column in the same row.)
I guess VARCHAR existed before BLOB/CLOB, so I am not so sure about that...
To me, CLOB is similar to a VARCHAR but can be significantly longer and
has reduced functionality (Why do you want to sort or join on a 4GB
CLOB?) As a database implementor it simplifies my work because I can
operate on the LOB in chunks instead of always materializing the whole
thing. During a complex join the LOBs are merged in only in the last
step when the result set is sent to the client, and the client may even
skip parts of the LOB it has no use for.
Roy
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
