Hello,
Konstantin Litvinenko wrote:
>>> In PostgreSQL backend you don't check field type
>> See src/backends/postgresql/statement.cpp, describe_column() function.
>
> This is totally unrelated to how into-type/use-type works.
Yes, you can argue that.
> Miciej, try to stop telling me how to DO NOT do some work. I know that
> you don't want to do it.
No, I only explain you why things are implemented this way. This is all
related to the considerations that were important at the time it was
implemented.
> Try to hear me.
> I have a problem. The problem live inside a problem domain. Problem
> domain described in term of
> unsigned ints.
I fully understand it.
> Try to answer to the questions:
> 1) Is it valuable addition for users that want to works directly with
> unsigned types?
I think so, but considering that the actual interest is very low, that
question is unrelated to whether it makes sense to do it.
> 2) What brakes for users that doesn't use unsigned types?
Hopefully nothing.
> 2) What brakes if we add such mapping in a whole?
It will be more work to implement (and test) new backends as there will
be more types to cover. This is what I would like to avoid.
> 3) Can it be implemented for existing backends?
I think so.
But I also have a question:
Can it be implemented in terms of user conversions?
Typing from my head, code was not tested:
namespace soci
{
template <>
struct type_conversion<unsigned int>
{
typedef long long base_type;
static void from_base(long long from, indicator ind, unsigned
int & to)
{
if (ind == i_null)
{
throw soci_error("Null value not allowed for this type");
}
to = static_cast<unsigned int>(from);
}
static void to_base(const unsigned int & from, long long & to,
indicator & ind)
{
to = static_cast<long long>(from);
ind = i_ok;
}
};
}
Please try to add this to your code.
I see no reason why it would not work.
> I can just implement stupid type_conversion for this mapping and be
> happy. But why this mapping
> can't live in library directly?
It can, just as there is such a mapping for boost::optional.
But this approach is completely different from extending the type
mapping in the library and generating more work in all backends.
The existing types allow to accommodate your request and that's why
there is no reason to modify the library.
Please let me know if the above works for you.
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
