Hi John and Thomas,

At the current time, the project is not centered on data security. It targets those who currently store their data as csv-s i-e data scientists and, really, gigantic arrays data and have a problem addressing them. I take their word as IT research academia that their work is at the forefront of technology:
https://hannes.muehleisen.org
I understood a couple of things I never did running through their recently decently understandable stuff. They are clearly great communicator. Remember where Guido came from as university background, the very same university. That possibly partly explains the pleasant reading even for relatively dummy vfp+sql db engines users such as myself:-)

>I can see why this might have value for Python or others without native cursor support like VFP, but IMHO persistent data has to be encrypted to
>demonstrate secure data for the likes of GDPR or HIPAA. Some years back I saw a US consulting and billing juggernaut effectively destroyed after an
>employee had stolen from his car, a notebook computer containing un-encrypted patient data.

I can really understand that. And that's why I have asked Hannes, the project leader to consider an ODBC layer as a way to better communicate information from and to the duckdb engine. He did.

The tool is already great as an upload tool since it can be fed straight from csv-s. I'll come back later to this very welcoming team with another series of proposals in terms of upload from python. Since the stuff can load straight from the file system, why just not for a start introduce the ubiquitous password-ed zipped formats as an alternative entry or fully shunt the file-system with generic python-iterator based feeder?

In my jolly farm of users, no csv users, of course since they handle management-related data. But enormously quantities of data stored in spreadsheets for analytical purposes, even in times of GDPR. Users still currently seem to accept the very limited security that spreadsheets will offer. But of course we care for them and addressing the issue is indeed part of our job. But it should in no way prevent those (bio-)scientists - the target - who have terabytes of raw data ,csv for a start, to include sql-based engines both as data repositories and retrieval mechanisms. SQL is not restricted to storage and sharing of management data. That's the message.

Daniel