Re: allow building trusted languages without the untrusted versions

Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
> On Tue, May 24, 2022 at 12:39:16PM -0400, Robert Haas wrote:
>> No, my point is that one size doesn't fit all. Bundling everything
>> together that could result in a disk access is going to suck too many
>> marginally-related into the same bucket. It's much better to have
>> individual switches controlling individual behaviors, so that people
>> can opt into or out of the behavior that they want.

> Can we do both? That is, can we add retail options for untrusted
> languages, generic file access functions, etc., and then also introduce a
> --disable-disk-access configuration option? The latter might even just be
> a combination of retail options. This would allow for more granular
> configurations, but it also could help address Tom's concerns.

Don't see why not.

I'm a bit skeptical of Robert's position, mainly because I don't think
he's offered any credible threat model that would justify disabling
individual features of this sort but not all of them. However, if what
it takes to have consensus is some individual knobs in addition to an
"easy button", let's do it that way.

regards, tom lane