Nikhil Benesch writes:
> On Mon, Jan 3, 2022 at 1:14 PM Tom Lane wrote:
>> Attached v3 restores that distinction, and makes some other small
>> tweaks. (I found that there were actually a couple of spots in
>> date.c that got it backwards, so admittedly this is a fine point
>> that not everybody
On Mon, Jan 3, 2022 at 1:14 PM Tom Lane wrote:
> Hmm, I think you went a bit too far here. The existing code intends
> to draw a distinction between "not recognized" (i.e., "we don't know
> what that word was you used") and "not supported" (i.e., "we know
> that word, but it doesn't seem to make
On 2022-Jan-03, Tom Lane wrote:
> Attached v3 restores that distinction, and makes some other small
> tweaks. (I found that there were actually a couple of spots in
> date.c that got it backwards, so admittedly this is a fine point
> that not everybody is on board with. But let's make it consist
Nikhil Benesch writes:
> Updated patch attached.
Hmm, I think you went a bit too far here. The existing code intends
to draw a distinction between "not recognized" (i.e., "we don't know
what that word was you used") and "not supported" (i.e., "we know
that word, but it doesn't seem to make sense
Updated patch attached.
On Mon, Jan 3, 2022 at 10:26 AM Nikhil Benesch wrote:
>
> On Mon, Jan 3, 2022 at 10:20 AM Tom Lane wrote:
> > BTW, if you want to get rid of the quotes, I think that something
> > else has to be done to set off the type name from the rest. In
> > this instance someone mi
On Mon, Jan 3, 2022 at 10:20 AM Tom Lane wrote:
> BTW, if you want to get rid of the quotes, I think that something
> else has to be done to set off the type name from the rest. In
> this instance someone might think that we're complaining about a
> "time zone unit", whatever that is. I suggest
Nikhil Benesch writes:
> - errmsg("\"time with time zone\" units \"%s\" not
> recognized",
> + errmsg("time with time zone units \"%s\" not
> recognized",
> [ etc ]
BTW, if you want to get rid of the quotes, I think that something
else has to be d
On Mon, Jan 3, 2022 at 10:11 AM Tom Lane wrote:
> Yeah, but we've been slowly converting to that method to reduce the number
> of distinct translatable strings for error messages. If doing so here
> would cut the labor for translators, I'm for it.
Great! I'll update the patch. Thanks for confirm
Nikhil Benesch writes:
> 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
On Mon, Jan 3, 2022 at 3:17 AM Michael Paquier 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
On Sun, Jan 02, 2022 at 11:47:32PM -0500, Nikhil Benesch wrote:
> The attached patch corrects a very minor typographical inconsistency
> when date_part is invoked with invalid units on time/timetz data vs
> timestamp/timestamptz/interval data.
Hmm, you are right that this is inconsistent, but I do
The attached patch corrects a very minor typographical inconsistency
when date_part is invoked with invalid units on time/timetz data vs
timestamp/timestamptz/interval data.
(If stuff like this is too minor to bother with, let me know and I'll
hold off in the future... but since this was pointed o
12 matches
Mail list logo
