On Fri, Mar 7, 2025 at 11:05 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Erik Wienhold <e...@ewie.name> writes: > > But I don't see the point in keeping variables atttypid and atttypmod > > around when those values are now available via outatt. Removing these > > two variables makes the code easier to read IMO. Done so in the > > attached v4. > > I think the idea of the original coding was to keep those values in > registers in the inner loop rather than re-fetching them each time. > But that's probably an unmeasurably microscopic optimization, if > real at all (modern compilers might figure it out for themselves).
> Do others agree Erik's version improves readability? > i think so. While looking at it, in build_attrmap_by_position I guess errmsg may be better than errmsg_internal since there are around 10 related error messages in src/pl/plpgsql/src/expected/plpgsql_record.out, so it's user visible. but I am confused by the below errmsg_internal comments about translation message infinite error recursion. /* * errmsg_internal --- add a primary error message text to the current error * * This is exactly like errmsg() except that strings passed to errmsg_internal * are not translated, and are customarily left out of the * internationalization message dictionary. This should be used for "can't * happen" cases that are probably not worth spending translation effort on. * We also use this for certain cases where we *must* not try to translate * the message because the translation would fail and result in infinite * error recursion. */
