On Tue, Jun 14, 2022 at 2:23 PM Peter Geoghegan <pg@bowt.ie> wrote:
> Maybe not -- it depends on the particulars of the code. For example,
> it might be okay for the B-Tree code to assume that B-Tree pages have
> a special area at a known fixed offset, determined at compile time. At
> the same time, it might very well not be okay for a backup tool to
> make any such assumption, because it doesn't have the same context.
>
> Even within TDE, it might be okay to assume that it's a feature that
> the user must commit to using for a whole cluster at initdb time. What
> isn't okay is committing to that assumption now and forever, by
> leaving the door open to a world in which that assumption no longer
> holds. Like when you do finally get around to making TDE something
> that can work at the relation level, for example. Even if there is
> only a small chance of that ever happening, why wouldn't we be
> prepared for it, just on general principle?
To the extent that we can leave ourselves room to do new things in the
future without incurring unreasonable costs in the present, I'm in
favor of that, as I believe anyone would be. But as you say, a lot
depends on the specifics. Theoretical flexibility that can only be
used in practice by really slow code doesn't help anybody.
--
Robert Haas
EDB: http://www.enterprisedb.com
