> Is it reasonable to ask cryptography experts to clone the entire SMGR > implementation and maintain code they don't fully understand just to > insert encryption logic?
You don't have to clone the md.c logic with the recent smgr extension patch, it does the same thing your patch does: it lets you hook into it while still keeping the original md.c implementation. The difference is that it doesn't add additional hooks to the API, instead it makes all of the existing smgr/md.c functions hooks. This also means that it lets different extensions work together in a more generic way. For example an extension that wants to retrieve data files from cloud storage when needed (prepending the original md.c logic), and an encryption extension that wants to decrypt data after loading it (appending to the original md.c logic) can both work together while keeping the original logic in place. Or if it's about mdwritev, in this patch you added a new mdwrite_pre_hook - but it is executed at a specific point during mdwrite. In the generic smgr patch, mdwritev itself (or smgr_writev more specifically) is a hook, you can change it, and then call the previous implementation (typically mdwritev) when you want it, either before or after your custom code. (the latest submitted version of the smgr patch doesn't use typical postgres-style hooks, but that's one of the things we probably should change. The intention is the same) There's no maintenance fee of cloning, because neither extension cloned the original md.c logic, both extended it.
