On 4/17/2016 9:45 AM, Simon Slavin wrote: > On 17 Apr 2016, at 1:02pm, William Drago <wdrago at verizon.net> wrote: > >> I am forced to consider this approach because my function will be receiving >> blobs but will have no idea what those blobs are. > Why do you care ? A BLOB is a BLOB. It doesn't matter whether it's an > integer, a string, a car, a peace treaty or the smell of newly cut grass. > You store it when told to and retrieve it when told to. My job is to find all the blob columns and unblob them into arrays of whatever type they originally were before they were blob'd. >> if this "feature" is not clearly documented someone in the future will have >> a very hard time figuring out why the blobs don't make sense. > BLOBs don't make sense. They're opaque. You are not meant to understand > anything about what's in a BLOB. That's for the layer of your software which > packs the information into a blob or unpacks the blob back into information. Understood. I'm writing the code that does the packing and unpacking. The users are designing their own databases. When they store for example, an array of 16 bit integers, or an array of 64 bit floats, I want to give them the same thing back when they query the database not just an array of bytes that they have to decode themselves.
Since I have control over how the blobs are generated, I can easily add a type identifier to each blob so that I know how to unblob it. -Bill
