Hello, Konstantin Litvinenko wrote:
> And what prevent me to map corresponding types to C++ types? The fact that this mapping is not 1:1. >> There is also a mapping in the other direction - for example, if the >> database returns something that has type SQL INTEGER, which of the C++ >> types should that map to? int or unsigned int? > > To that type I request. Is it not obvious?! Consider the column_properties::get_data_type() function and the example code here: http://soci.sourceforge.net/doc/exchange.html#dynamic > More over you do support unsigned long. What is corresponding SQL type for > that? What is > corresponding PostgreSQL type? OID. The unsigned long was supported *specifically* to allow users work with OIDs and I think that without this use-case unsigned types would not be supported at all. > In PostgreSQL backend you don't check field type See src/backends/postgresql/statement.cpp, describe_column() function. > Again. What prevents adding support of unsigned short and unsigned int as > first citizen in SOCI? Again. The fact that the mapping is not 1:1 and that it is not clear whether the use-case is substantial enough to warrant additional work. Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
