út 10. 3. 2026 v 19:09 odesílatel Tom Lane <[email protected]> napsal:
> Matthias van de Meent <[email protected]> writes: > > 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). > > I think that'd be a lot of work with little result other than to > change what sort of manual validation you have to do. Today, you > have to check "does the function's actual C code match the SQL > definition?". But with this, you'd have to check "does the function's > actual C code match the pg_finfo record?". I'm not seeing a huge win > there. > > Many many years ago when we first designed V1 function call protocol, > I had the idea that we could write a tool that inspects C code like > > Datum > int42pl(PG_FUNCTION_ARGS) > { > int32 arg1 = PG_GETARG_INT32(0); > int16 arg2 = PG_GETARG_INT16(1); > int32 result; > > and automatically derives (or at least cross-checks against) the SQL > definition. And we probably still could write such a tool. But > there's a large fraction of the code base where no attention was paid > to following that layout, and/or one C function was made to handle > several signatures by writing conditional logic to fetch the > arguments. Maybe you could get an AI tool to disentangle such logic, > but how much you wanna trust the results? > > FmgrInfo holds fn_oid - so maybe it can holds proallargtypes too, and then some assertation can be injected to PG_GETARG_X macros without massive slowdown. Regards Pavel > regards, tom lane > > >
