You're correct that there is a minor inefficiency, once a tupDesc_identifier version mismatch is detected, the patch allocates
new_values/new_nulls arrays and calls deconstruct_expanded_record() before knowing whether any field types actually differ.
If the version changed but no field types changed (e.g., a constraint-only ALTER), we do unnecessary work and hit the if (!need_conversion) return late.
That said, your suggestion is clean and correct. I can restructure the code to do a first pass over the TupleDesc attributes (which is pure metadata, no deconstruction needed) to set need_conversion,
and only proceed with deconstruct_expanded_record() and array allocation if that returns true. This avoids any unnecessary memory allocation in that intermediate case.
