On Fri, Mar 7, 2025 at 11:05 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Erik Wienhold <ewie@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.
*/
