develooper Front page | perl.perl5.porters | Postings from August 2021

DBD::SQLite WAS Re: "use v5.36.0" should imply UTF-8 encoded source

Thread Previous | Thread Next
From:
Felipe Gasper
Date:
August 3, 2021 00:40
Subject:
DBD::SQLite WAS Re: "use v5.36.0" should imply UTF-8 encoded source
Message ID:
17CC7FDC-2ACA-4EC6-B194-50C72C43FCFA@felipegasper.com


> On Aug 2, 2021, at 4:28 PM, Harald Jörg <haj@posteo.de> wrote:
> 
> Dan Book <grinnz@gmail.com> writes:
> 
>> DBD::MariaDB, DBD::SQLite, and DBD::Pg are used with the unicode
>> option in any modern programs. Thus they expect decoded strings.
> 
> As far as DBD::SQLite is concerned, this is only half-true.  In the
> current version 1.70 there have been changes how to declare unicode
> handling, but even with DBD_SQLITE_STRING_MODE_UNICODE_STRICT you can
> feed it UTF-8 encoded byte sequences and it "just works" (but maybe
> shouldn't).

Perl has no way of making it *not* work, alas.

> 
> You see the downside of this when you have a non-ASCII literal in a
> iso-latin-1 encoded Perl source (e.g. "ä" or "\x{e4}").  For Perl, it is
> the same character as "\N{LATIN SMALL LETTER A WITH DIAERESIS}", but if
> you feed both to the database you get different results.

This should no longer be the case if you avoid DBD_SQLITE_STRING_MODE_PV.

> It seems that the driver still inspects the infamous UTF-8-flag to
> decide whether a literal is encoded or not.

This is not the case, except with DBD_SQLITE_STRING_MODE_PV, which for backward compatibility reasons remains the default.

-FG
Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About