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
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?
regards, tom lane
