On Tue, 10 Mar 2026 at 17:19, Nico Williams <[email protected]> wrote: > > On Tue, Mar 10, 2026 at 09:23:50AM -0400, Robert Haas wrote: > > [...]. The example that started this thread is > > essentially unpreventable, because we need CREATE FUNCTION to be > > possible and we need the superuser to tell us what the C code is > > expecting, but the number of people who go tinkering with catalog > > contents manually without fully understanding the consequences seems > > to be much larger than I would have thought, even if the tinkering is > > usually less dramatic than this example. > > If DWARF is available you could always get the C function's > prototype from that, and sanity-check it. But DWARF really bloats > shared objects, and it's not universal, so it's not a good solution.
Even with DWARF analysis it wouldn't help for C-language SQL functions, as their signature is fixed: their one and only argument is always just an FunctionCallInfo aka FunctionCallInfoBaseData*. That struct then contains the actual arguments/argument count/nullability info. Also note that the "c" language here effectively only means "dynamically loaded symbol using standard C linking with the platform's C calling convention": PostgreSQL doesn't compile the functions from sources. Any language that compiles to a binary that links with such symbols should work; e.g. C++ and Rust are both using this mechanism despite the "c" name used for the language. Kind regards, Matthias van de Meent Databricks (https://www.databricks.com)
