Re: RFC: PostgreSQL Storage I/O Transformation Hooks

> 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.