Phil Endecott wrote:
When necessary, the approach that I've taken is for the client to define the expected data type, but to do this using a cast inside the SQL string:
"select salary::int64 from ..."
You can then be fairly certain that you'll actually get a 64-bit value back.
Then at execution time, all I do is a quick check that the retuned column types are the expected ones, and throw if they aren't.
This is a big burden on the user and is very fragile. Consider: typedef int SalaryType; // ... SalaryType salary; sql << "select salary from ...", into(salary); Not only it is not clear at the use point what type should be put in the textual query, but whatever you put there will fail just a few months later when you upgrade the source code and change the typedef in the one place where it is defined. Facilitating such changes is one of the purposes of typedef, after all. Note also that the above solution is impractical if queries are not encoded in source code, but exist externally, for example in resource files (or even in a database). The same query might be reused in many places, even if the target data type might be different. Note also that calling stored procedures is tricky/impractical with this approach, because result types are encoded in the signature or definition of the procedure and are not normally exposed in the query that calls it. Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com