On Tue, 2023-01-10 at 11:45 -0500, Robert Haas wrote: > So the risks, which in theory are all very similar, are in practice > far greater in the PostgreSQL context, basically because our default > setup is about 40 years behind the times in terms of implementing > best > practices.
I agree that huge improvements could be made with improvements to best practices/defaults. But there are some differences that are harder to fix that way. In postgres, one can attach arbitrary code to pretty much anything, so you need to trust everything you touch. There is no safe postgres equivalent to grepping an untrusted file. > It might be best to repost some of these ideas on a new thread with a > relevant subject line, but I agree that there's some potential here. > Your first idea reminds me a lot of the proposal Tom made in > https://www.postgresql.org/message-id/19327.1533748...@sss.pgh.pa.us > -- except that his mechanism is more general, since you can say whose > code you trust and whose code you don't trust. Noah had a competing > version of that patch, too. But we never settled on an approach. I > still think something like this would be a good idea, and the fact > that you've apparently-independently come up with a similar notion > just reinforces that. Will do, thank you for the reference. -- Jeff Davis PostgreSQL Contributor Team - AWS
