Joe Conway <mail@joeconway.com> writes:
>> On the other hand, your experience yesterday with debugging a mismatched
>> function declaration suggests that it's still a good idea to make the
>> functions build the tupdesc they think they are returning.
> In a function which *can* know what the tupledec should look like based
> on independent information (contrib/tablefunc.c:crosstab), or based on a
> priori knowledge (guc.c:show_all_settings), then the passed in tupdesc
> could be used by the function to validate that it has been acceptably
> declared (for named types) or called (for anonymous types).
Yeah, I had also considered the idea of pushing the responsibility of
verifying the tupdesc matching out to the function (ie, nodeFunctionscan
wouldn't call tupdesc_mismatch anymore, but the function could).
I think this is a bad idea on balance though; it would save few cycles
and probably create lots more debugging headaches like the one you had.
regards, tom lane