On Tue, Mar 28, 2023 at 5:02 AM Stephen Frost <sfr...@snowman.net> wrote:
> > > There's clearly user demand for it as there's a number of organizations >> > who have forks which are providing it in one shape or another. This >> > kind of splintering of the community is actually an actively bad thing >> > for the project and is part of what killed Unix, by at least some pretty >> > reputable accounts, in my view. >> >> Yes, the number of commercial implementations of this is a concern. Of >> course, it is also possible that those commercial implementations are >> meeting checkbox requirements rather than technical ones, and the >> community has been hostile to check box-only features. > > > I’ve grown weary of this argument as the other major piece of work it was > routinely applied to was RLS and yet that has certainly been seen broadly > as a beneficial feature with users clearly leveraging it and in more than > some “checkbox” way. > > Indeed, it’s similar also in that commercial implementations were done of > RLS while there were arguments made about it being a checkbox feature which > were used to discourage it from being implemented in core. Were it truly > checkbox, I don’t feel we would have the regular and ongoing discussion > about it on the lists that we do, nor see other tools built on top of PG > which specifically leverage it. Perhaps there are truly checkbox features > out there which we will never implement, but I’m (perhaps due to what my > dad would call selective listening on my part, perhaps not) having trouble > coming up with any presently. Features that exist in other systems that we > don’t want? Certainly. We don’t characterize those as simply “checkbox” > though. Perhaps that’s in part because we provide alternatives- but that’s > not the case here. We have no comparable way to have this capability as > part of the core system. > > We, as a community, are clearly losing value by lack of this capability, > if by no other measure than simply the numerous users of the commercial > implementations feeling that they simply can’t use PG without this feature, > for whatever their reasoning. > I also think this is something of a problem because very few requirements are actually purely technical requirements, and I think the issue is that in many cases there are ways around the lack of the feature. So I would phrase this differently. What is the value of doing this in core? This dramatically simplifies the question of setting up a PostgreSQL environment that is properly protected with encryption at rest. That in itself is valuable. Today you can accomplish something similar with encrypted filesystems and encryption options in things like pgbackrest. However these are many different pieces of a solution and missing up the setup of any one of them can compromise the data. Having a single point of encryption and decryption means fewer opportunities to mess it up and that means less risk. This in turn makes it easier to settle on using PostgreSQL. There are certainly going to be those who approach encryption at rest as a checkbox item and who don't really care if there are holes in it. But there are others who really should be concerned (and this is becoming a bigger issue where data privacy, PCI-DSS, and other requirements may come into play), and those need better tooling than we have. I also think that as data privacy becomes a larger issue, this will become a larger topic. Anyway, my contribution to that question. Best Wishes, Chris Travers > > Thanks, > > Stephen > -- Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more
