On Tue, Mar 10, 2026 at 8:03 AM Matthias van de Meent <[email protected]> wrote: > Correct. This is expected behaviour: the "internal" and "c" languages > are not 'trusted' languages, and therefore only superusers can create > functions using these languages. It is the explicit responsibility of > the superuser to make sure the functions they create using untrusted > languages are correct and execute safely when called by PostgreSQL.
Agreed! In fact, it's pretty much theoretically impossible for this to work any other way. If we wanted to add checks that the expectations of the C code match the actual function definitions, how would we do that? I'm tempted to say we'd have to solve the halting problem (which is impossible, look it up), but the 2026 reality is that someone would just say "deploy an AI agent to check whether the code is safe for the definition," and that might actually work in practical cases, but we're not going to add a call-out to Claude as part of the CREATE FUNCTION statement. And it's equally impossible to insist that every C function anyone writes must be prepared for an arbitrary number of arguments of arbitrary data types. Even doing that for core functions would be a massive waste of resources. Functions like +(int4,int4) can be called in very tight loops, and even the fact that those functions do overflow checking is a significant performance drain. Doing these kinds of checks to counter hypothetical scenarios would be a poor investment of resources that would make many users unhappy. Besides, even if we did that, we couldn't possibly enforce that out-of-core C code has all of the same checks, or that those checks are correctly coded. Basically, yeah, being able to call code written directly in C is dangerous, but it's also necessary, because that's how we get reasonable performance. -- Robert Haas EDB: http://www.enterprisedb.com
