On Mon, Jan 3, 2022 at 3:17 AM Michael Paquier <michael@paquier.xyz> wrote:
> However, there is a specific routine called format_type_be() aimed at
> formatting type names for error strings. If you switch to that, my
> guess is that this makes the error messages of time/timetz and
> timestamp/timestamptz/interval more consistent, while reducing the
> effort of translation because we'd finish with the same base error
> string, as of "%s units \"%s\" not recognized".
I could find only a tiny smattering of examples where format_type_be()
is invoked with a constant OID. In almost all error messages where the
type is statically known, it seems the type name is hardcoded into the
error message rather than generated via format_type_be(). For example,
all of the "TYPE out of range" errors.
I'm happy to rework the patch to use format_type_be(), but wanted to
double check first that it is the preferred approach in this
situation.