SQLite Forum

Kind request: Please make SHA3/? part of built-in functions
Login

Kind request: Please make SHA3/? part of built-in functions

(1) By anonymous on 2020-08-22 11:17:35 [link] [source]

There are numerous occasions where record contents need to be verified. At least outside the personal/hobbyist realm.

Some popular hash function (preferably SHA3 but any other would be OK also, if there are code size considerations) seems very appropriate to be part of the built-in set of available SQLite3 functions in the amalgamation, even if only enabled under some conditional directive.

Ideally, the result should be a hex string, but there is already a hex function, so either way would be fine.

One could sometimes include such hash function at the application layer but that would not allow internal SQLite3 processing from using it (e.g., triggers).

Thank you.

(2) By Larry Brasfield (LarryBrasfield) on 2020-08-22 15:04:16 in reply to 1 [link] [source]

You are, of course, welcome to build your own version of the SQLite library or shell with the SHA3 extension built in.

The reason that all the sometimes useful extensions are optional, rather than forced into every build, is because the 'Lite' part of SQLite is a real feature, taken seriously by the developers and appreciated by many clients who target smaller platforms.

When incorporated into a build instead of being a separate dynamically linked library, the extension code acts in nearly all respects just like built-in functions do.

(3) By anonymous on 2020-08-23 09:31:40 in reply to 2 [link] [source]

The reason that all the sometimes useful extensions are optional, rather than forced into every build, is because the 'Lite' part of SQLite is a real feature, taken seriously by the developers and appreciated by many clients who target smaller platforms.

True but IMO irrelevant if an optional feature is disabled by default (hence, OPTIONAL) and enabled only via some compile time define. Those who don't want to 'bloat' their copy with unused to them features won't have to do anything different from before.

When incorporated into a build instead of being a separate dynamically linked library, the extension code acts in nearly all respects just like built-in functions do.

Why then not incorporate this (SHA3) and all other 'official' extensions in the amalgamation code, disabled by default yet easily available to enable with a simple turn of a compile time define 'switch'?

As I'm one of those who would like a fully 'bloated' version of SQLite3 (all bells and whistles available) I would also like to propose the introduction of a single define 'switch' that enables all possible feature adding options at once.

(Perhaps, for those who like minimalist versions, a similar 'switch' to disable all but the absolutely necessary.)

(4) By Adrian Ho (lexfiend) on 2020-08-23 11:09:18 in reply to 3 [link] [source]

Why then not incorporate this (SHA3) and all other 'official' extensions in the amalgamation code, disabled by default yet easily available to enable with a simple turn of a compile time define 'switch'?

Because then any bugfix/enhancement of any extension would require publishing an entirely new amalgamation. Would you want to have to track which releases affect the particular extensions you use, and which don't?

(5) By anonymous on 2020-08-23 12:18:45 in reply to 4 [link] [source]

Not really. You don't get a new amalgamation with every bug fixed on trunk, do you? Why would extensions be any different? Wait until next release.

(6) By Larry Brasfield (LarryBrasfield) on 2020-08-23 12:37:33 in reply to 3 [link] [source]

A frequent forum participant, Keith Medcalf, has published in this post (and others) a collection of extensions along with a function, defined in coreinit.c, which loads a gob of extensions. As the README.txt file in the same archive explains, by using a compile flag, -DSQLITE_EXTRA_INIT=core_init, and appending the gob sources in the right order to the amalgamation, they can be statically linked and their names made known to the SQLite statement compiler.

It would be nearly trivial to adapt Keith's core_init() code to load any set of extensions you like, with whatever conditional compilation you see fit to devise.

Should this be included with the amalgamation when it is released? It will be ever-growing, just as the set of extensions published at sqlite.org has grown. Maybe you can persuade the SQLite developers to list it in the 3rd-party tools collection.

Personally, I prefer the simplicity of the amalgamation as it is, and I would prefer it not be larded up with the text of all the extensions. However, a conditional #include "gob_of_extensions.c" in the right place would not be detrimental to the present simplicity.

(7) By anonymous on 2020-08-23 14:20:24 in reply to 6 [source]

However, a conditional

 #include "gob_of_extensions.c"
in the right place would not be detrimental to the present simplicity.

That's a good compromise, if possible.

Maybe the extensions could also be amalgamated to their own single file to keep it in the same spirit, but not necessarily.