Re: Remove inconsistent quotes from date_part error

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.

In response to

Responses

Browse pgsql-hackers by date

  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