On 24 June 2013 14:36, Vadim Zeitlin <[email protected]> wrote:
> On Sun, 23 Jun 2013 13:03:32 +0200 (CEST) "[email protected]" 
> <[email protected]> wrote:
>
> hs> My plan is to clone the ODBC backend and come up with a first version
> hs> of a new MSSQL interface.
>
>  Hello,
>
>  Having a native MS SQL backend would be very nice to have in any case,
> even independently of the Unicode issues, so it would be definitely great
> to at least start working on this.

I agree.

> hs> But there is a global issue doing so. I need the extends the core with
> hs> support of
> hs>
> hs> #define SQL_WCHAR             (-8)
> hs> #define SQL_WVARCHAR         (-9)
> hs>
> hs> with a new core data_type
> hs>
> hs>       dt_wstring
> hs>
> hs> and exchanged to
> hs>
> hs>      std::wstring.
>
>  This would be already useful and AFAICS shouldn't be a big problem to
> implement but I think it would be really useful to also allow exchange
> between Unicode database fields and UTF-8-encoded std::string (no "w").
> What do you think?

UTF-8 is Unicode, but I guess it's a shortcut.

Do you mean a field of UTF-8 and select into(std::wstring)
or field of UTF-16 and insert with use(std::string) ?

> hs> Should the support additionally enrolled to any other backend too if
> hs> the backend is able to support such types using std::wstring?
>
>  Ideally all this should be backend-independent, of course.

Yes, but there is set of common types and conversions.

> Even if the backend doesn't specifically support Unicode at all, we could 
> just encode
> std::wstring in UTF-8 and use the existing code. In fact, I'd think that
> this would be the right thing to do for all the other backends but I didn't
> actually check it.

In fact, currently, we somewhat implicitly assume all std::sting are UTF-8.

If a database speaks UTF-8 only, then it surely is feasible
to use std::wstring as into/use type, as we can apply conversion.
Semantically, it would be equivlent to integer promotion or conversion.
But, that is not the end of the story.

In limited scenario, we can assume only MSSQL/ODBC on Windows
exchange UTF-16 and all the rest exchange UTF-8, then we know
statically what conversion to apply.

The problem is if we want to support conversions like:
anything <->UTF-8
anything <->UTF-16

Then we have to take care of checking what lingo database/client/backend
speak per session.  Don't we?

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users

Reply via email to