út 10. 3. 2026 v 19:09 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Matthias van de Meent <boekewurm+postgres@gmail.com> 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
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.
