On Mon, Oct 7, 2019 at 3:01 PM Antonin Houska <a...@cybertec.at> wrote: > However the design doesn't seem to be stable enough at the > moment for coding to make sense.
Well, I think the question is whether working further on your patch could produce some things that everyone would agree are a step forward. If every iota of that patch is garbage dredged up from the depths of the Mos Eisley sewers, then let's forget about it, but I don't think that's the case. As I said on the thread about that patch, and have also said here, what I learned from looking at that patch is that the system probably needs some significant restructuring before there's any hope of incorporating encryption in a reasonably-sized, reasonably clean patch. For example, some files need to be written a block at a time instead of a character at a time. The idea just discussed -- changing the CLOG page format to leave room for the encryption nonce and a checksum -- also fall into that category. I think there are probably a number of others. No matter what anybody thinks about whether we should have one key, multiple keys, passwords inside the database, passwords outside the database, whatever ... that kind of restructuring work has got to be done first. And it seems like by having all this discussion about the design, we're basically getting to a situation where we're making no progress on that stuff. So that's bad. There's nothing *wrong* with talking about how many keys we had and how key management ought to work and where passwords should be stored, and we need to make sure that whatever we do initially doesn't close the door to doing more and better things later. But, if those discussions have the effect of blocking work on the basic infrastructure tasks that need to be done, that's actually counterproductive at this stage. We should all put our heads together and agree that however we think key management ought to be handled, it'll be a lot easier to get our preferred form of key management into PostgreSQL if, while that discussion rages on, we knocked down some of the infrastructure problems that *absolutely any patch* for this kind of feature is certain to face. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company