Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas

On Thu, Apr 7, 2022 at 1:09 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > > I got that much, of course. That will work, I suppose, but it'll be
> > > the first and last time that anybody gets to do that (unless we accept
> > > it being incompatible with encryption).
> >
> > Yeah.
>
> I don't know that I agree with this being the 'first and last time'..?
> If we have two options that could work together and each need some
> amount of per-page space, such as a nonce or authentication tag, we'd
> just need to be able to track which of those are enabled (eg: through
> pg_control) and then know which gets what space.

Sounds very messy.

> I don't see why we
> couldn't add something today and then add something else later on.

That's what I'm arguing in favor of, in part.

> I'm also doubtful about how well this would work, but the other question
> is- what would be the advantage to doing it this way? If we could have
> it be run-time instead of initdb-time, that'd be great (imagine a
> database that's encrypted while another isn't in the same cluster, or
> even individual tables, which would all be very cool), but I don't think
> this approach would make that possible..?

That would be the main advantage, yes. But I also tend to doubt that
we should make it completely impossible to know anything at all about
the page without fully decrypting it.

It was just a suggestion. I will leave it at that.

--
Peter Geoghegan