There is no sqlite3_result_subtype() becuase there is no sqlite3_bind_subtype()
becuase the subtype of a value cannot be stored in the database. That is my
point. I don't know what you mean by your second paragraph, but subtype here is
just an attribute of a value, similar to it's type (in
Users of a sqlite3_bind_subtype() wouldn't expect those bits to be
persisted to disk considering that a function returned column value
presented to INSERT or UPDATE doesn't have sqlite3_result_subtype() bits
recorded. Does that make a difference to your answer?
You can't have sqlite3_bind_subtype() because it would require a change to the
database file format - there would be no real performance penalty besides
increased record size. There is no existing place to store a per-value subtype
in the file format as it stands, although I did have a design
1. Why are these functions missing from the obtaining/setting pages? Are
they not recommended for some reason? I'd like to know if they are on the
way out because, obviously, these solve the BLOB typing problem for
functions directly and I'm now using them.
4 matches
Mail list logo
