> On 11/10/19, Richard Hipp wrote:
> > It seems there are also problems in generating valid JSON for large
> > unicode characters. For example:
> >
> > SELECT json_quote(char(1114111));
> >
> > I'm working on the problem
> I take that back. It seems that the spec allow arbitrary UTF-8
I now believe that check-in
https://www.sqlite.org/src/timeline?c=51027f08c0478f1b is the complete
and correct fix for the reported problem with UTF16 surrogate pairs in
JSON. I have checked in new test cases (to TH3, where, unfortunately,
you cannot see them). If anybody sees anything that I
On 11/10/19, Richard Hipp wrote:
> It seems there are also problems in generating valid JSON for large
> unicode characters. For example:
>
> SELECT json_quote(char(1114111));
>
> I'm working on the problem
I take that back. It seems that the spec allow arbitrary UTF-8
characters in a
It seems there are also problems in generating valid JSON for large
unicode characters. For example:
SELECT json_quote(char(1114111));
I'm working on the problem
--
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
On 11/8/19, Serhiy Storchaka wrote:
> JSON_EXTRACT [1] produces gibberish for encoded non-BMP characters.
Thanks for the bug report and test case.
I checked in candidate fix here:
https://www.sqlite.org/src/timeline?c=51027f08c0478f1b
I need to do additional testing, and due to conflicting
> On Nov 10, 2019, at 4:03 AM, Richard Damon wrote:
>
> Actually, 'The Artist whose name formerly was Prince' (which wasn't his
> name, his legal name was an unpronounceable pictograph), breaks every
> computer system I know.
Unicode Character PRINCE (U+1F934)
And "full legal name" How about my dad, whose full name was Dr. John
Michael Patrick Dennis Emmet O'Gorman, PhD. How many rules does that
break? I've fought many companies over that apostrophe in my life.
Governments tend to throw it away, but it's on my old passport and birth
certificate.
On 4 Nov 2019, at 22:25, Jens Alfke wrote:
>> On Nov 4, 2019, at 4:57 AM, Simon Slavin wrote:
>>
>> That's one of the reasons that the source code for SQLite is public: so that
>> people can add the features they want.
>
> Totally agree. However, when you go off the mainline of SQLite you lose
On 11/10/19 1:21 AM, Gary R. Schmidt wrote:
> On 10/11/2019 13:44, Doug wrote:
>> Au Contraire, Jens! In many local contexts you can normalize people's
>> names. I was born in Kansas, USA. My parents filled out a birth
>> certificate for me. It had a place on the form for first name, middle
>>
On 10 Nov 2019, at 6:21am, Gary R. Schmidt wrote:
> So what happens when someone from a family who only uses first- and
> last-names moves to Kansas?
In my time with databases, I encountered several USAsians with a middle name of
'Nmn'. I know many USAsian people but nobody with this name.
On 8 Nov 2019, at 10:02pm, MA LIG wrote:
> I've tried other permutations of various flags that go along for
> sqlite3_open_v2 , as well as setting pragma read_uncommitted, but can't
> seem to get multi-threaded concurrent rapid-fire querying to work at all.
Please set a timeout of at least 5000
On 10/11/2019 13:44, Doug wrote:
Au Contraire, Jens! In many local contexts you can normalize people's names. I
was born in Kansas, USA. My parents filled out a birth certificate for me. It
had a place on the form for first name, middle name, last name, and a suffix
like II or III.
That
JSON_EXTRACT [1] produces gibberish for encoded non-BMP characters. Example:
sqlite> SELECT JSON_EXTRACT('"t\u00e8\u015b\ud835\udd99"', '$');
tèś��
Expected result is "tèś햙".
Since character "햙" (U+1D599) is not in the Basic Multilingual Plane,
it is encoded as the UTF-16
Hi,
Am using the API and having trouble (deadlock or crash) with multithreaded
access to a read-only sqlite3 file. Any help would be much appreciated.
- Running OSX with sqlite3 3.28.0 amalgamation compiled from code. Same
issue is occurring when the code is compiled for Windows using
14 matches
Mail list logo
