On Tue, 10 Mar 2026 at 13:26, Robert Haas <[email protected]> wrote: > > 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.
Tangent: I think it could be possible to make extensions (and PG itself) generate more extensive pg_finfo records that contain sufficient information to describe the functions' expected SQL calling signature(s), which PG could then check and verify when the function is catalogued (e.g. through lanvalidator). E.g. "this function has 2 PG calling signatures: a volatile function with 2 non-null arguments, or an immutable function with 3 non-null arguments". Registrations which conflict with the exposed definition could then raise a warning to expose the difference. This would make the gap between C code and SQL code that needs to be bridged by manual superuser validation a bit smaller. I won't claim it's trivial, but I do think it might be a worthwile time investment, and extensions could benefit here, too, as such metadata could be used to validate and/or generate parts of extension's install/upgrade scripts. (And, whilst this is not on my personal todo list, it's definitely on my wishlist; so do with the idea what you would like). Kind regards, Matthias van de Meent Databricks (https://www.databricks.com)
