Print a warning if use_index is turned on but libmswstr is not found. I
suppose we could enable indexes only on JET3 databases, but I am not at
all confident in the JET3 index logic, as it seems to break on non-ASCII
input. So I'd rather just print this warning and require some
hoop-jumping.
* Migrate the Windows Msys2 build from Appveyor to GitHub Actions
* Fix build with newer versions of Msys2 (fix `vasprintf` conflict)
* Enable SQL tests on the Cygwin build on Appveyor
* Fix an error message about Bison not being available when in fact Flex was not available
* Don't fail fast with Mac and Linux GitHub Actions
src/libmdb/backend.c:mdb_print_indexes() and
src/libmdb/backend.c:mdb_get_relationships(): In PostgreSQL the INDEX
names explicitly must not have a namespace name on them; they are always
created in the namespace of the table. See:
http://www.postgresql.org/docs/current/static/sql-createindex.html
which says: "The name of the index to be created. No schema name can be
included here; the index is always created in the same schema as
its parent table."
By observation the same is true for CONSTRAINT names; they are refused
if the namespace is included before them.
Also omit the namespace from the FOREIGN KEY constraint _column_ names
on PostgreSQL (it's not clear that the _column_ names should ever be
namespaced, but behaviour should currently be unchanged for databases
other than PostgreSQL).
According to the HACKING file, the file's default language ID is stored
in the database header. Use this value instead of a generic English
language locale for indexing JET4 files.
Columns can have their own text sorting rules, including language ID
distinct from the file's language ID, but this is not addressed as we'd
have to break the mdb_index_hash_text function signature, which I'm not
prepared to do just yet.
There appear to be two bytes after the language ID that may indicate
additional sorting flags. These bytes need additional research.
Using the notes and RC4 key provided in the HACKING file, decrypt the
database definition page all at once instead of decrypting individual
fields with ad-hoc keys. Use the newly decrypted header to access the
database code page at offset 0x3C, and use this numeric value to
initialize the iconv converter with an appropriate charset name for
popular windows code pages. More encodings can be added later, with
the eventual goal of getting rid of the MDB_JET3_CHARSET environment
variable.
Note that individual columns can have their own code pages but this
issue is not addressed.
An extra field is added to the MdbFile structure - because this
struct is allocated internally, this should not break the public
ABI.
Finally, only set the db_passwd field if it's a JET3 database (see #144)
Replace the jerry-built UTF-16 => Latin-1 code path with a cross-platform wcstombs solution that emits UTF-8.
This adds an element to the end of the MdbHandle struct, but should not break any existing code.
A run-time option could be added later to emit other encodings, but people who care about such things can just use the iconv code path.
Merge in pull request #108 with a few changes:
* Use the newer mdb_print_col function
* Redefine the last argument of mdb_print_col to be a flags argument
* Rename and redefine the BINEXPORT enums. While technically public,
these were never intended as a public API.
* Name the command line option --escape-c
There was some confusion as to whether the destination buffer length
should include space for the null terminator. Some callers of the
function assumed that a terminator would be added beyond the end
of the stated buffer size, while others did not. Make everything
consistent and also fix an overrun when there was insufficient
space for the output in the non-iconv implementation.
As stated in a code comment, a better solution would follow the lead
of libxls and use wcstombs and friends when iconv is not available.
But this gets into the weeds with conversion functions named differently
across platforms. The goal here is to fix the buffer overrun.
See oss-fuzz/28773
