From: | Nikhil Benesch <nikhil(dot)benesch(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Remove inconsistent quotes from date_part error |
Date: | 2022-01-03 14:53:52 |
Message-ID: | CAPWqQZRa58atSHDgbDraAAo2371zBdmcAej7e-=8g+YxJa35uA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 3, 2022 at 3:17 AM Michael Paquier <michael(at)paquier(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-01-03 14:57:14 | Re: Index-only scans vs. partially-retrievable indexes |
Previous Message | Justin Pryzby | 2022-01-03 14:40:57 | Re: Column Filtering in Logical Replication |